unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el
@ 2013-06-20 21:15 Drew Adams
  2016-04-28 23:58 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2013-06-20 21:15 UTC (permalink / raw)
  To: 14680

emacs -Q

Add files named isearch+.el, isearch+.el~, and isearch+.elc to the
current directory, then (add-to-list 'load-path ".")  Then eval this:

(completing-read "Library name: " 
                 'locate-file-completion
                 (cons load-path (find-library-suffixes))
                 nil nil nil (thing-at-point 'symbol))

Then type `isearch+ TAB TAB'.  The candidates shown are these:

isearch+          isearch+.elc
isearch+.elc.elc  isearch+.el~

There should be no *.elc.elc here, and there should be *.el (missing).

The problem seems to arise when `locate-file-completion-table' invokes:
(file-name-all-completions "isearch+" ".").  That returns this:
("isearch+.el~" "isearch+.elc.elc" "isearch+.elc" "isearch+.el")

Then, since "isearch+.el" is matched by "\\(\\.el\\(?:\\.gz\\)?\\)\\'",
it is not included as a candidate.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-18 on LEG570
Bzr revision: 113050 handa@gnu.org-20130618145521-fvpc5viqtc85j4j4
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''





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

* bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el
  2013-06-20 21:15 bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el Drew Adams
@ 2016-04-28 23:58 ` Lars Ingebrigtsen
  2016-04-29 17:01   ` Drew Adams
  0 siblings, 1 reply; 5+ messages in thread
From: Lars Ingebrigtsen @ 2016-04-28 23:58 UTC (permalink / raw)
  To: Drew Adams; +Cc: 14680

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

> Add files named isearch+.el, isearch+.el~, and isearch+.elc to the
> current directory, then (add-to-list 'load-path ".")  Then eval this:

[...]

> The problem seems to arise when `locate-file-completion-table' invokes:
> (file-name-all-completions "isearch+" ".").  That returns this:
> ("isearch+.el~" "isearch+.elc.elc" "isearch+.elc" "isearch+.el")

(file-name-all-completions "isearch+" ".")
=>
("isearch+.elc" "isearch+.el" "isearch+.el~")

So I'm unable to reproduce this error.  Is this from -Q?

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





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

* bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el
  2016-04-28 23:58 ` Lars Ingebrigtsen
@ 2016-04-29 17:01   ` Drew Adams
  2016-08-30  1:44     ` npostavs
  0 siblings, 1 reply; 5+ messages in thread
From: Drew Adams @ 2016-04-29 17:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 14680

> > Add files named isearch+.el, isearch+.el~, and isearch+.elc to the
> > current directory, then (add-to-list 'load-path ".")  Then eval this:
> [...]
> 
> So I'm unable to reproduce this error.  Is this from -Q?

Yes, it is reproducible (on MS Windows, at least), using (at least)
Emacs 24 and an Emacs 25 build of a month or so ago.

However, the recipe should have said to do this also, before 
evaluating the `completing-read' sexp:

(load-library "find-func")





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

* bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el
  2016-04-29 17:01   ` Drew Adams
@ 2016-08-30  1:44     ` npostavs
  2016-08-30  2:24       ` Drew Adams
  0 siblings, 1 reply; 5+ messages in thread
From: npostavs @ 2016-08-30  1:44 UTC (permalink / raw)
  To: Drew Adams; +Cc: Lars Ingebrigtsen, 14680

tags 14680 unreproducible
quit

Drew Adams <drew.adams@oracle.com> writes:
> Yes, it is reproducible (on MS Windows, at least), using (at least)
> Emacs 24 and an Emacs 25 build of a month or so ago.
>
> However, the recipe should have said to do this also, before 
> evaluating the `completing-read' sexp:
>
> (load-library "find-func")

Not able to reproduce on Windows 10; Emacs 24.3, 24.4, 24.5, 25.1-rc1

I tested in a directory with contents:

C:\Users\npostavs\src\emacs>dir /b bug-14680-locate-file-completion
bug-14680.el
isearch+.el
isearch+.elc
isearch+.el~

Evaluated the following from emacs -Q:

(load-library "find-func")
(add-to-list 'load-path ".")
(completing-read "Library name: "
                 'locate-file-completion
                 (cons load-path (find-library-suffixes))
                 nil nil nil (thing-at-point 'symbol))

I got

Possible completions are:
isearch+
isearch+.elc
isearch+.el~






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

* bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el
  2016-08-30  1:44     ` npostavs
@ 2016-08-30  2:24       ` Drew Adams
  0 siblings, 0 replies; 5+ messages in thread
From: Drew Adams @ 2016-08-30  2:24 UTC (permalink / raw)
  To: npostavs; +Cc: Lars Ingebrigtsen, 14680

> tags 14680 unreproducible
> quit

Thanks for testing.  This was my bad, I think.  Sorry.





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

end of thread, other threads:[~2016-08-30  2:24 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-20 21:15 bug#14680: 24.3.50; `locate-file-completion' gives wrong candidates - *.elc.elc and no *.el Drew Adams
2016-04-28 23:58 ` Lars Ingebrigtsen
2016-04-29 17:01   ` Drew Adams
2016-08-30  1:44     ` npostavs
2016-08-30  2:24       ` 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).