unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#15735: 24.3.50; `find-library' completion bug
@ 2013-10-27 17:36 Drew Adams
  2013-10-28  4:07 ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2013-10-27 17:36 UTC (permalink / raw)
  To: 15735

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'





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-27 17:36 bug#15735: 24.3.50; `find-library' completion bug Drew Adams
@ 2013-10-28  4:07 ` Stefan Monnier
  2013-10-28 14:00   ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2013-10-28  4:07 UTC (permalink / raw)
  To: Drew Adams; +Cc: 15735

> 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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28  4:07 ` Stefan Monnier
@ 2013-10-28 14:00   ` Drew Adams
  2013-10-28 14:32     ` Andreas Röhler
  2013-10-28 14:53     ` Stefan Monnier
  0 siblings, 2 replies; 13+ messages in thread
From: Drew Adams @ 2013-10-28 14:00 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28 14:00   ` Drew Adams
@ 2013-10-28 14:32     ` Andreas Röhler
  2013-10-28 14:39       ` Drew Adams
  2013-10-28 14:53     ` Stefan Monnier
  1 sibling, 1 reply; 13+ messages in thread
From: Andreas Röhler @ 2013-10-28 14:32 UTC (permalink / raw)
  To: 15735

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?





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28 14:32     ` Andreas Röhler
@ 2013-10-28 14:39       ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2013-10-28 14:39 UTC (permalink / raw)
  To: Andreas Röhler, 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28 14:00   ` Drew Adams
  2013-10-28 14:32     ` Andreas Röhler
@ 2013-10-28 14:53     ` Stefan Monnier
  2013-10-28 15:06       ` Drew Adams
  1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2013-10-28 14:53 UTC (permalink / raw)
  To: Drew Adams; +Cc: 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28 14:53     ` Stefan Monnier
@ 2013-10-28 15:06       ` Drew Adams
  2013-10-29  1:25         ` Stefan Monnier
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2013-10-28 15:06 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-28 15:06       ` Drew Adams
@ 2013-10-29  1:25         ` Stefan Monnier
  2013-10-29  1:28           ` Drew Adams
  2022-02-05 23:29           ` bug#15735: locate-file-completion-table should not accept incomplete input Lars Ingebrigtsen
  0 siblings, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2013-10-29  1:25 UTC (permalink / raw)
  To: Drew Adams; +Cc: 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: 24.3.50; `find-library' completion bug
  2013-10-29  1:25         ` Stefan Monnier
@ 2013-10-29  1:28           ` Drew Adams
  2022-02-05 23:29           ` bug#15735: locate-file-completion-table should not accept incomplete input Lars Ingebrigtsen
  1 sibling, 0 replies; 13+ messages in thread
From: Drew Adams @ 2013-10-29  1:28 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15735

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

Sounds good. Thx.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: locate-file-completion-table should not accept incomplete input
  2013-10-29  1:25         ` Stefan Monnier
  2013-10-29  1:28           ` Drew Adams
@ 2022-02-05 23:29           ` Lars Ingebrigtsen
  2022-02-06  0:17             ` bug#15735: [External] : " Drew Adams
  1 sibling, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-05 23:29 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 15735

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input
  2022-02-05 23:29           ` bug#15735: locate-file-completion-table should not accept incomplete input Lars Ingebrigtsen
@ 2022-02-06  0:17             ` Drew Adams
  2022-02-06  0:18               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Drew Adams @ 2022-02-06  0:17 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Stefan Monnier; +Cc: 15735@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input
  2022-02-06  0:17             ` bug#15735: [External] : " Drew Adams
@ 2022-02-06  0:18               ` Lars Ingebrigtsen
  2022-02-06  0:29                 ` Drew Adams
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-02-06  0:18 UTC (permalink / raw)
  To: Drew Adams; +Cc: Stefan Monnier, 15735@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#15735: [External] : Re: bug#15735: locate-file-completion-table should not accept incomplete input
  2022-02-06  0:18               ` Lars Ingebrigtsen
@ 2022-02-06  0:29                 ` Drew Adams
  0 siblings, 0 replies; 13+ messages in thread
From: Drew Adams @ 2022-02-06  0:29 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Monnier, 15735@debbugs.gnu.org

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-02-06  0:29 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-10-27 17:36 bug#15735: 24.3.50; `find-library' completion bug Drew Adams
2013-10-28  4:07 ` Stefan Monnier
2013-10-28 14:00   ` Drew Adams
2013-10-28 14:32     ` Andreas Röhler
2013-10-28 14:39       ` Drew Adams
2013-10-28 14:53     ` Stefan Monnier
2013-10-28 15:06       ` Drew Adams
2013-10-29  1:25         ` Stefan Monnier
2013-10-29  1:28           ` Drew Adams
2022-02-05 23:29           ` bug#15735: locate-file-completion-table should not accept incomplete input Lars Ingebrigtsen
2022-02-06  0:17             ` bug#15735: [External] : " Drew Adams
2022-02-06  0:18               ` Lars Ingebrigtsen
2022-02-06  0:29                 ` Drew Adams

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).