bug#15735: 24.3.50; `find-library' completion bug

bug#15735: 24.3.50; `find-library' completion bug

[Drew Adams]

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@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'

bug#15735: 24.3.50; `find-library' completion bug

[Stefan Monnier]

> 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

bug#15735: 24.3.50; `find-library' completion bug

[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.

bug#15735: 24.3.50; `find-library' completion bug

[Andreas Röhler]

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?

bug#15735: 24.3.50; `find-library' completion bug

[Drew Adams]

> 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.

bug#15735: 24.3.50; `find-library' completion bug

[Stefan Monnier]

>> 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

bug#15735: 24.3.50; `find-library' completion bug

[Drew Adams]

> > 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.

bug#15735: 24.3.50; `find-library' completion bug

[Stefan Monnier]

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

bug#15735: 24.3.50; `find-library' completion bug

[Drew Adams]

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

Sounds good. Thx.

bug#15735: locate-file-completion-table should not accept incomplete input

[Lars Ingebrigtsen]

Stefan Monnier <monnier@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

bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input

[Drew Adams]

> 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?

bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input

[Lars Ingebrigtsen]

Drew Adams <drew.adams@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

bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input

[Drew Adams]

> >> 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.