GNU bug report logs - #36945
27.0.50; read-library-name

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 36945 in the body.
You can then email your comments to 36945 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: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; read-library-name
Date: Tue, 6 Aug 2019 11:48:12 +0200

[Message part 1 (text/plain, inline)]

Hi,

read-library-name offers <name> and <name>.elc for each library name.
I expect that .elc names should not be offered.

This is running `emacs -Q`.

However, with a standard configuration using ELPA/MELPA, the situation
is much worse, as I get stuff like:

../
../
../
./
.dir-locals
.elpaignore
.elpaignore
.git
.git

in the list of propositions. These are obviously not library names.

Regards,



In GNU Emacs 27.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-07-31 built on Marvin
Repository revision: 1be15d443a0e346351029a90cb04906408b3a75d
Repository branch: wsl
Windowing system distributor 'Moba/X', version 11.0.12004000
System Description: Ubuntu 18.04.2 LTS

Recent messages:
Scanning for dabbrevs...done
user-error: No dynamic expansion for ‘read-libr’ found
Entering debugger...
Back to top level
Loading find-func...done
Making completion list...
Quit
(".el" ".el.gz")
Type C-x 1 to delete the help window.
Making completion list...
Quit
Configured using:
 'configure --prefix=/usr/local --without-imagemagick'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LC_ALL: C.UTF-8
  value of $LC_CTYPE: C.UTF-8
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date subr-x seq byte-opt gv
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils completion dos-w32 find-cmd
grep compile comint ansi-color ring find-dired dired dired-loaddefs
thingatpt help-fns radix-tree cl-print debug backtrace help-mode
easymenu find-func cl-loaddefs cl-lib dabbrev tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 85513 6636)
 (symbols 48 7341 1)
 (strings 32 21210 1730)
 (string-bytes 1 656125)
 (vectors 16 11115)
 (vector-slots 8 143137 9722)
 (floats 8 25 50)
 (intervals 56 9262 0)
 (buffers 992 14))

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 36945 <at> debbugs.gnu.org
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Fri, 23 Aug 2019 06:55:28 +0200

Fabrice Popineau <fabrice.popineau <at> gmail.com> writes:

> read-library-name offers <name> and <name>.elc for each library name.
> I expect that .elc names should not be offered.
>
> This is running `emacs -Q`.
>
> However, with a standard configuration using ELPA/MELPA, the situation
> is much worse, as I get stuff like:
>
> ../
> ../
> ../
> ./
> .dir-locals
> .elpaignore
> .elpaignore
> .git
> .git
>
> in the list of propositions. These are obviously not library names.

The function basically calls this function:

(locate-file-completion-table '("~/src/emacs/trunk/lisp/image") '(".el$") "" nil t)
=> ("compface.el" "compface.elc" "../" "gravatar.elc" "./" "gravatar.el")

And as we can see, the output from that function isn't quite what you'd
expect.  Isn't SUFFIXES supposed to limit the output?

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

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Mon, 26 Aug 2019 10:55:04 -0400

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> (locate-file-completion-table '("~/src/emacs/trunk/lisp/image") '(".el$") "" nil t)
> => ("compface.el" "compface.elc" "../" "gravatar.elc" "./" "gravatar.el")
>
> And as we can see, the output from that function isn't quite what you'd
> expect.  Isn't SUFFIXES supposed to limit the output?

In the context of general file name completion, I guess the idea is that
you might find files with any extension under a directory.  Doesn't make
so much sense for read-library-name though.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Tue, 27 Aug 2019 09:48:42 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> (locate-file-completion-table '("~/src/emacs/trunk/lisp/image")
>> '(".el$") "" nil t)
>> => ("compface.el" "compface.elc" "../" "gravatar.elc" "./" "gravatar.el")
>>
>> And as we can see, the output from that function isn't quite what you'd
>> expect.  Isn't SUFFIXES supposed to limit the output?
>
> In the context of general file name completion, I guess the idea is that
> you might find files with any extension under a directory.  Doesn't make
> so much sense for read-library-name though.

No, I wonder if whoever wrote the code in question thought that SUFFIXES
limited the results...  which it doesn't seem to do.  Those completion
functions are a bit under-documented, though.

I've now rewritten `read-library-name' to not use that function at all,
and instead just complete over all the .el/.el.gz files "manually".

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Fabrice Popineau <fabrice.popineau <at> gmail.com>
Cc: 36945 <at> debbugs.gnu.org
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Mon, 14 Sep 2020 16:46:05 -0400

> read-library-name offers <name> and <name>.elc for each library name.
> I expect that .elc names should not be offered.

I think it should indeed not be displayed when `<name>` is already
listed alongside others, but when the users type `<name> TAB` it would
make sense to list the `.elc` file since it's quite possible that they
want to choose between the `.el` and the `.elc` version of the file.

> .dir-locals
> .elpaignore
> .elpaignore
> .git
> .git
>
> in the list of propositions. These are obviously not library names.

~/.emacs is a common name for a file that can be loaded, so I will
object to it being "obvious".  Also, while `.git` should preferably not
be listed, `.git/` arguably could since you might keep Elisp files in
there.

So I think we should list all directories, but I agree we should
probably strip away all files whose name doesn't end in `.el`, `.elc`,
`.el.gz` (and any other such extension in `load-suffixes`), and we
should ideally only list the extension when it's the only
remaining choice.

Oh, and another reason to keep files that don't just end in `.el` is
when you want to load `foo.el.BAK` or `foo.el~`, so maybe we should only
skip those files which don't have `.el` somewhere in their name :-(


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Tue, 15 Sep 2020 14:32:58 +0200

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

> ~/.emacs is a common name for a file that can be loaded, so I will
> object to it being "obvious".  Also, while `.git` should preferably not
> be listed, `.git/` arguably could since you might keep Elisp files in
> there.
>
> So I think we should list all directories, but I agree we should
> probably strip away all files whose name doesn't end in `.el`, `.elc`,
> `.el.gz` (and any other such extension in `load-suffixes`), and we
> should ideally only list the extension when it's the only
> remaining choice.

read-library-name has slightly unclear semantics -- I didn't know that
it was supposed to complete over directory names at all.  Perhaps that
should be mentioned in the doc string?

> Oh, and another reason to keep files that don't just end in `.el` is
> when you want to load `foo.el.BAK` or `foo.el~`, so maybe we should only
> skip those files which don't have `.el` somewhere in their name :-(

Hm...  perhaps the function is just misnamed.  When I want to find a
library, I really do want to complete over the library's name, and
nothing else.  What read-library-name does, however, is file name
completion over load-path, which is something a bit different.

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Tue, 15 Sep 2020 09:31:05 -0400

> read-library-name has slightly unclear semantics -- I didn't know that
> it was supposed to complete over directory names at all.  Perhaps that
> should be mentioned in the doc string?

I take it to mean "read an argument appropriate for `load`".


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 36945 <at> debbugs.gnu.org, fabrice.popineau <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Tue, 15 Sep 2020 17:48:19 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Tue, 15 Sep 2020 14:32:58 +0200
> Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
> 
> Hm...  perhaps the function is just misnamed.  When I want to find a
> library, I really do want to complete over the library's name, and
> nothing else.

Since load-library must support the use case when the user forces to
load the .el file, not the .elc file, read-library-name must allow
library names with extensions, I think.  IOW, the "library" in this
context is just the basename of its file name, with or without the
extension.

Message #45 received at 36945 <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: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: RE: bug#36945: 27.0.50; read-library-name
Date: Tue, 15 Sep 2020 15:32:19 +0000 (UTC)

> Hm...  perhaps the function is just misnamed.  When I want to find a
> library, I really do want to complete over the library's name, and
> nothing else.  What read-library-name does, however, is file name
> completion over load-path, which is something a bit different.

I don't think the name is bad.  It's just that we have
different ideas of what a "library name" is.  The same
thing happens with file names.  You're talking about a
sort of "base" name.

My suggestion: Improve the `read-library-name' doc to
make clear what it does (whatever you think isn't clear
enough).  And then provide another function that does
what you were wanting/expecting.

Or if you find an easy way to get the behavior you want
as optional behavior by tweaking `read-library-name',
make that change, so the same function can do both things.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36945 <at> debbugs.gnu.org, fabrice.popineau <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Thu, 17 Sep 2020 16:40:24 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Since load-library must support the use case when the user forces to
> load the .el file, not the .elc file, read-library-name must allow
> library names with extensions, I think.  IOW, the "library" in this
> context is just the basename of its file name, with or without the
> extension.

Yeah.  So I think the request in 36945 can't be done -- Emacs has to
complete over all files in load-path, no matter what they're called,
really.

I'm not sure what context the request was made in (since it's not
stated), but I thought about it from a `find-library' context.

Which should probably use something like the patch that was reverted,
but put into its own function.

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

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, fabrice.popineau <at> gmail.com,
 36945 <at> debbugs.gnu.org
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Thu, 17 Sep 2020 12:41:36 -0400

>> Since load-library must support the use case when the user forces to
>> load the .el file, not the .elc file, read-library-name must allow
>> library names with extensions, I think.  IOW, the "library" in this
>> context is just the basename of its file name, with or without the
>> extension.
> Yeah.  So I think the request in 36945 can't be done -- Emacs has to
> complete over all files in load-path, no matter what they're called,
> really.

Yes and no.  The behavior could be similar to what we do with
`completion-ignored-extensions` (where those files are only ignored if
there are others), e.g. for an input "i" we'd list ("icomplete"
"image" ...)  but for an input "icomplet" we'd list
("icomplete.el" "icomplete.elc" "icomplete.el.BAK").


        Stefan

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 36945 <at> debbugs.gnu.org, Fabrice Popineau <fabrice.popineau <at> gmail.com>
Subject: Re: bug#36945: 27.0.50; read-library-name
Date: Sun, 06 Feb 2022 00:31:20 +0100

Noam Postavsky <npostavs <at> gmail.com> writes:

> In the context of general file name completion, I guess the idea is that
> you might find files with any extension under a directory.  Doesn't make
> so much sense for read-library-name though.

I've now added a user option that allows completing over library names
only in Emacs 29:

(setq find-library-include-other-files nil)

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

Previous Next

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