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

Previous Next

Full log

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

Previous Next

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