GNU bug report logs - #15735
locate-file-completion-table should not accept incomplete input

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15735 in the body.
You can then email your comments to 15735 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; `find-library' completion bug
Date: Sun, 27 Oct 2013 10:36:59 -0700 (PDT)

emacs -Q

I add directory`ess-5.3.10' to my `load-path'.  That dir has a
subdirectory `lisp', which contains libraries whose names begin with
`ess', such as `ess.el'.  (But subdir `lisp' is not in `load-path'.)

M-x find-library ess TAB

completes to `ess-5.3.10', which it should not.  There is no library in
my `load-path' that has that prefix.

`RET' with the completion `ess-5.3.10' raises an error (naturally):

Debugger entered--Lisp error: (error "Can't find library ess-5.3.10/")
  signal(error ("Can't find library ess-5.3.10/"))
  error("Can't find library %s" "ess-5.3.10/")
  find-library-name("ess-5.3.10/")
  (find-file-noselect (find-library-name library))
  (let ((buf (find-file-noselect (find-library-name library)))) (condition-case nil (switch-to-buffer buf) (error (pop-to-buffer buf))))
  find-library("ess-5.3.10/")
  call-interactively(find-library record-it)
...

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-10-19 on LEG570
Bzr revision: 114715 rgm <at> gnu.org-20131019023520-s8mwtib7xcx9e05w
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'

Message #8 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15735 <at> debbugs.gnu.org
Subject: Re: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 00:07:31 -0400

> completes to `ess-5.3.10', which it should not.  There is no library in
[...]
> Debugger entered--Lisp error: (error "Can't find library ess-5.3.10/")

From this error message, it looks like it did not complete to
"ess-5.3.10" but to "ess-5.3.10/", from which I gather that this is the
directory you added (you added it inside a directory which is itself in
load-path).
So that looks perfectly correct.  Or am I misunderstanding something?


        Stefan

Message #11 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15735 <at> debbugs.gnu.org
Subject: RE: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 07:00:45 -0700 (PDT)

> > Debugger entered--Lisp error: (error "Can't find library ess-
> > 5.3.10/")
> 
> From this error message, it looks like it did not complete to
> "ess-5.3.10" but to "ess-5.3.10/", from which I gather that this is
> the directory you added (you added it inside a directory which is
> itself in load-path).

That's right.  It is a subdirectory of a directory in `load-path'.
It is not, itself, in `load-path'.

> So that looks perfectly correct.  Or am I misunderstanding
> something?

It doesn't seem right to me, but I'm probably naive.  I wouldn't
think that it should be a completion at all, since (a) it is not
itself an Emacs-Lisp library in the load-path and (b) there are
no such libraries within it.  I would expect TAB to say that there
are no completions.

I would expect that even if this directory were itself a member
of the load-path (which it is not).

But if this is the intended design, no problem.  It just didn't
seem like TRT to me.  IOW, I didn't expect it.

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 15:32:07 +0100

Am 28.10.2013 15:00, schrieb Drew Adams:
>>> Debugger entered--Lisp error: (error "Can't find library ess-
>>> 5.3.10/")
>>
>>  From this error message, it looks like it did not complete to
>> "ess-5.3.10" but to "ess-5.3.10/", from which I gather that this is
>> the directory you added (you added it inside a directory which is
>> itself in load-path).
>
> That's right.  It is a subdirectory of a directory in `load-path'.
> It is not, itself, in `load-path'.
>
>> So that looks perfectly correct.  Or am I misunderstanding
>> something?
>
> It doesn't seem right to me, but I'm probably naive.  I wouldn't
> think that it should be a completion at all, since (a) it is not
> itself an Emacs-Lisp library in the load-path and (b) there are
> no such libraries within it.  I would expect TAB to say that there
> are no completions.
>
> I would expect that even if this directory were itself a member
> of the load-path (which it is not).
>
> But if this is the intended design, no problem.  It just didn't
> seem like TRT to me.  IOW, I didn't expect it.
>
>
>
>

Maybe the difficulty raises from the fact of the prefic being part of the directory name, which seems causing conflict?

Message #17 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Andreas Röhler <andreas.roehler <at> easy-emacs.de>,
 15735 <at> debbugs.gnu.org
Subject: RE: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 07:39:13 -0700 (PDT)

> Maybe the difficulty raises from the fact of the prefic being part
> of the directory name, which seems causing conflict?

Sorry, not sure what you mean.  Dunno whether there is any conflict.
I just didn't expect that it would successfully complete to a directory
that is not in `load-path', and hence cannot possibly contain libraries
that are in the `load-path'.

IOW, I was thinking that Emacs should be able to tell me, at completion
time, what it tells me if I hit RET for that directory: no library.

Message #20 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15735 <at> debbugs.gnu.org
Subject: Re: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 10:53:05 -0400

>> So that looks perfectly correct.  Or am I misunderstanding
>> something?

> It doesn't seem right to me, but I'm probably naive.

You can do (load "ess-5.3.10/somefile"), and for that reaon you can do
You can do M-x load-library RET ess-5.3.10/somefile RET, and for that
reason, you can do M-x load-library RET ess- TAB somefi TAB RET

This is not used with many packages, but it is used for (load
"term/xterm.el") since "term/" is not in load-path, and it is used
extensively for CEDET where the subdirectories are used for "namespace",
so they can load "semantic/debug" without colliding with Emacs's debug.el.


        Stefan

Message #23 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15735 <at> debbugs.gnu.org
Subject: RE: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 08:06:01 -0700 (PDT)

> > It doesn't seem right to me, but I'm probably naive.
> 
> You can do (load "ess-5.3.10/somefile"), and for that reaon you can
> do
> You can do M-x load-library RET ess-5.3.10/somefile RET, and for
> that
> reason, you can do M-x load-library RET ess- TAB somefi TAB RET
> 
> This is not used with many packages, but it is used for (load
> "term/xterm.el") since "term/" is not in load-path, and it is used
> extensively for CEDET where the subdirectories are used for
> "namespace", so they can load "semantic/debug" without colliding
> with Emacs's debug.el.

OK.

Perhaps what is the most confusing to me is that instead of Emacs
telling you that there are no completions of what you've typed,
it tells you that this (the dir) is a successful completion, and
yet if you hit RET it tells you no library.

It would make more sense to me if RET at this point did what I
expected a second TAB to do: tell you there are no completions
(beyond the directory name), but not exit the minibuffer.

More generally, perhaps RET for `find-library' should not exit
the minibuffer for unsuccesful library-finding.

I'm OK with your closing the bug, but I wonder whether a less
surprising behavior might not be possible.

Message #26 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 15735 <at> debbugs.gnu.org
Subject: Re: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 21:25:01 -0400

retitle 15735 locate-file-completion-table should not accept incomplete input
thanks

> It would make more sense to me if RET at this point did what I
> expected a second TAB to do: tell you there are no completions
> (beyond the directory name), but not exit the minibuffer.

Yes, that makes sense.  Indeed, there's a problem in the completion
system: we don't distinguish between a valid input and a completion
candidate.  "ess-5.3.10/" is a valid completion candidate, but is not
a valid input.

IIRC there are cases where the completion primitives make it difficult
to enforce this distinction (e.g. when we provide a predicate, where it
can be OK to ignore the predicate on intermediate completions like
"ess-5.3.10/"), but in the case of load-library's completion, it should
be fixable without too much trouble.


        Stefan

Message #31 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15735 <at> debbugs.gnu.org
Subject: RE: bug#15735: 24.3.50; `find-library' completion bug
Date: Mon, 28 Oct 2013 18:28:04 -0700 (PDT)

> in the case of load-library's completion, it
> should be fixable without too much trouble.

Sounds good. Thx.

Message #34 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15735 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#15735: locate-file-completion-table should not accept
 incomplete input
Date: Sun, 06 Feb 2022 00:29:13 +0100

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> IIRC there are cases where the completion primitives make it difficult
> to enforce this distinction (e.g. when we provide a predicate, where it
> can be OK to ignore the predicate on intermediate completions like
> "ess-5.3.10/"), but in the case of load-library's completion, it should
> be fixable without too much trouble.

I've now introduced a new user option find-library-include-other-files
in Emacs 29 that makes `read-library-name' (and therefore
`find-library') behave differently -- if set to nil, it'll offer
completion over library files and nothing else.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #39 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: "15735 <at> debbugs.gnu.org" <15735 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#15735: locate-file-completion-table should
 not accept incomplete input
Date: Sun, 6 Feb 2022 00:17:22 +0000

> I've now introduced a new user option find-library-include-other-files
> in Emacs 29 that makes `read-library-name' (and therefore
> `find-library') behave differently -- if set to nil, it'll offer
> completion over library files and nothing else.

Thanks.  But what's the default behavior, nil or non-nil?

Message #42 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 "15735 <at> debbugs.gnu.org" <15735 <at> debbugs.gnu.org>
Subject: Re: [External] : Re: bug#15735: locate-file-completion-table should
 not accept incomplete input
Date: Sun, 06 Feb 2022 01:18:24 +0100

Drew Adams <drew.adams <at> oracle.com> writes:

>> I've now introduced a new user option find-library-include-other-files
>> in Emacs 29 that makes `read-library-name' (and therefore
>> `find-library') behave differently -- if set to nil, it'll offer
>> completion over library files and nothing else.
>
> Thanks.  But what's the default behavior, nil or non-nil?

Non-nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #45 received at 15735 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 "15735 <at> debbugs.gnu.org" <15735 <at> debbugs.gnu.org>
Subject: RE: [External] : Re: bug#15735: locate-file-completion-table should
 not accept incomplete input
Date: Sun, 6 Feb 2022 00:29:27 +0000

> >> I've now introduced a new user option find-library-include-other-files
> >> in Emacs 29 that makes `read-library-name' (and therefore
> >> `find-library') behave differently -- if set to nil, it'll offer
> >> completion over library files and nothing else.
> >
> > Thanks.  But what's the default behavior, nil or non-nil?
> 
> Non-nil.

So we're back to Square 1.  Guess this should be
filed under "won't fix" instead of "done".

Instead of fixing it, e.g. as Stefan indicated,
you chose to give users an option to fix it
themselves, but the default value of the option
doesn't fix it for them.

da> It would make more sense to me if RET at this
da> point did what I expected a second TAB to do:
da> tell you there are no completions (beyond the
da> directory name), but not exit the minibuffer.

sm> Yes, that makes sense.  Indeed, there's a problem in the completion system: we don't distinguish between a valid input and a completion candidate.  "ess-5.3.10/" is a valid completion candidate, but is not a valid input.

sm> IIRC there are cases where the completion primitives make it difficult to enforce this distinction (e.g. when we provide a predicate, where it can be OK to ignore the predicate on intermediate completions like "ess-5.3.10/"), but in the case of load-library's completion, it should be fixable without too much trouble.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.