GNU bug report logs -
#68022
30.0.50; File cache completions accumulate instead of replacing minibuffer input
Previous Next
To reply to this bug, email your comments to 68022 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 06:55:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Eshel Yaron <me <at> eshelyaron.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 25 Dec 2023 06:55:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
With emacs -Q:
1. M-x file-cache-add-directory-using-find /path/to/emacs/
2. C-x C-f mini C-TAB
3. Observe the *Completions* buffer pop up with file cache
completions, suggesting as usual to "type M-<down> or M-<up> to move
point between completions."
4. M-<down> M-<down> M-<up> ...
5. Each candidate you highlight this way is inserted in the minibuffer
after the current input, instead of replacing the appropriate part of
the input.
I see this already in Emacs 29.1, FWIW.
Best,
Eshel
In GNU Emacs 30.0.50 (build 7, x86_64-apple-darwin23.0.0, NS
appkit-2487.00 Version 14.0 (Build 23A344)) of 2023-12-23
Repository revision: 1727e1f8462009b461976f45957e47de6d34c6eb
Repository branch: main
Windowing system distributor 'Apple', version 10.3.2487
System Description: macOS 14.0
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 12:46:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 68022 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 25 Dec 2023 07:54:22 +0100
> From: Eshel Yaron via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
>
> With emacs -Q:
>
> 1. M-x file-cache-add-directory-using-find /path/to/emacs/
> 2. C-x C-f mini C-TAB
> 3. Observe the *Completions* buffer pop up with file cache
> completions, suggesting as usual to "type M-<down> or M-<up> to move
> point between completions."
> 4. M-<down> M-<down> M-<up> ...
> 5. Each candidate you highlight this way is inserted in the minibuffer
> after the current input, instead of replacing the appropriate part of
> the input.
>
> I see this already in Emacs 29.1, FWIW.
Something is missing in the recipe above, because I get "No match"
when I press C-TAB in step 2. What did I miss? Is the above supposed
to work in any Emacs source tree? Also, what should be the
default-directory in step 1 (if it's important) -- should it be the
root of the Emacs source tree?
Thanks.
P.S. Btw, C-TAB doesn't get bound on a TTY, even though I can emulate
C-TAB by typing "C-x @ c TAB".
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 13:49:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 68022 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Mon, 25 Dec 2023 07:54:22 +0100
>> From: Eshel Yaron
>>
>> With emacs -Q:
>>
>> 1. M-x file-cache-add-directory-using-find /path/to/emacs/
>> 2. C-x C-f mini C-TAB
>> 3. Observe the *Completions* buffer pop up with file cache
>> completions, suggesting as usual to "type M-<down> or M-<up> to move
>> point between completions."
>> 4. M-<down> M-<down> M-<up> ...
>> 5. Each candidate you highlight this way is inserted in the minibuffer
>> after the current input, instead of replacing the appropriate part of
>> the input.
>>
>> I see this already in Emacs 29.1, FWIW.
>
> Something is missing in the recipe above, because I get "No match"
> when I press C-TAB in step 2. What did I miss?
Hmm, I'm not sure. Perhaps `file-cache-add-directory-using-find` didn't
do its job for some reason? The point is just to add a bunch of file
names to the cache.
> Is the above supposed to work in any Emacs source tree? Also, what
> should be the default-directory in step 1 (if it's important) --
> should it be the root of the Emacs source tree?
That shouldn't matter, I think, as long as you have several files with
"mini" in their names in the cache. Any other invocation of `C-TAB`
that pops the *Completions* buffer should show the same behavior AFAICT.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 15:06:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 68022 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 68022 <at> debbugs.gnu.org
> Date: Mon, 25 Dec 2023 14:47:52 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Date: Mon, 25 Dec 2023 07:54:22 +0100
> >> From: Eshel Yaron
> >>
> >> With emacs -Q:
> >>
> >> 1. M-x file-cache-add-directory-using-find /path/to/emacs/
> >> 2. C-x C-f mini C-TAB
> >> 3. Observe the *Completions* buffer pop up with file cache
> >> completions, suggesting as usual to "type M-<down> or M-<up> to move
> >> point between completions."
> >> 4. M-<down> M-<down> M-<up> ...
> >> 5. Each candidate you highlight this way is inserted in the minibuffer
> >> after the current input, instead of replacing the appropriate part of
> >> the input.
> >>
> >> I see this already in Emacs 29.1, FWIW.
> >
> > Something is missing in the recipe above, because I get "No match"
> > when I press C-TAB in step 2. What did I miss?
>
> Hmm, I'm not sure. Perhaps `file-cache-add-directory-using-find` didn't
> do its job for some reason?
How do I verify that? Could you perhaps show at least some of the
cache and tell how to compare that with what I get here?
> > Is the above supposed to work in any Emacs source tree? Also, what
> > should be the default-directory in step 1 (if it's important) --
> > should it be the root of the Emacs source tree?
>
> That shouldn't matter, I think, as long as you have several files with
> "mini" in their names in the cache.
If I invoke 'find' from the shell prompt, I get this:
D:\gnu\git\emacs\branch>find . -name "mini*"
./doc/emacs/mini.texi
./doc/lispref/minibuf.texi
./lib/mini-gmp-gnulib.c
./lib/mini-gmp.c
./lib/mini-gmp.h
./lisp/minibuf-eldef.el
./lisp/minibuf-eldef.elc
./lisp/minibuffer.el
./lisp/minibuffer.elc
./src/deps/minibuf.d
./src/minibuf.c
./src/minibuf.o
./test/lisp/minibuffer-resources
./test/lisp/minibuffer-resources/data/minibuffer-test-cttq$tion
./test/lisp/minibuffer-tests.el
./test/lisp/minibuffer-tests.elc
./test/src/minibuf-tests.el
Do you get something very different?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 15:42:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 68022 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 68022 <at> debbugs.gnu.org
>> Date: Mon, 25 Dec 2023 14:47:52 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Date: Mon, 25 Dec 2023 07:54:22 +0100
>> >> From: Eshel Yaron
>> >>
>> >> With emacs -Q:
>> >>
>> >> 1. M-x file-cache-add-directory-using-find /path/to/emacs/
>> >> 2. C-x C-f mini C-TAB
>> >> 3. Observe the *Completions* buffer pop up with file cache
>> >> completions, suggesting as usual to "type M-<down> or M-<up> to move
>> >> point between completions."
>> >> 4. M-<down> M-<down> M-<up> ...
>> >> 5. Each candidate you highlight this way is inserted in the minibuffer
>> >> after the current input, instead of replacing the appropriate part of
>> >> the input.
>> >>
>> >> I see this already in Emacs 29.1, FWIW.
>> >
>> > Something is missing in the recipe above, because I get "No match"
>> > when I press C-TAB in step 2. What did I miss?
>>
>> Hmm, I'm not sure. Perhaps `file-cache-add-directory-using-find` didn't
>> do its job for some reason?
>
> How do I verify that?
`M-x file-cache-display` should show the cache contents.
> Could you perhaps show at least some of the cache and tell how to
> compare that with what I get here?
Sure, here's what I see after `M-x keep-lines RET mini RET` in the
output buffer of `M-x file-cache-display`:
--8<---------------cut here---------------start------------->8---
/Users/eshelyaron/emacs-29.1/src/deps/minibuf.d
/Users/eshelyaron/emacs-29.1/src/minibuf.c
/Users/eshelyaron/emacs-29.1/native-lisp/29_1_50-1fe1a1fd/preloaded/minibuffer-1b0f548b-7af20c5f.eln
/Users/eshelyaron/emacs-29.1/doc/emacs/mini.texi
/Users/eshelyaron/emacs-29.1/doc/lispref/minibuf.texi
/Users/eshelyaron/emacs-29.1/lib/mini-gmp.c
/Users/eshelyaron/emacs-29.1/lib/mini-gmp.h
/Users/eshelyaron/emacs-29.1/lib/mini-gmp-gnulib.c
/Users/eshelyaron/emacs-29.1/test/src/minibuf-tests.el
/Users/eshelyaron/emacs-29.1/test/lisp/minibuffer-tests.el
/Users/eshelyaron/emacs-29.1/test/lisp/minibuffer-resources/data/minibuffer-test-cttq$tion
/Users/eshelyaron/emacs-29.1/test/lisp/minibuffer-resources/lisp/cedet/semantic-utest-c.test
/Users/eshelyaron/emacs-29.1/test/lisp/minibuffer-resources/lisp/cedet/semantic-utest.test
/Users/eshelyaron/emacs-29.1/test/lisp/minibuffer-resources
/Users/eshelyaron/emacs-29.1/lisp/minibuf-eldef.el
/Users/eshelyaron/emacs-29.1/lisp/minibuffer.el
/Users/eshelyaron/emacs-29.1/lisp/use-package/use-package-diminish.el
--8<---------------cut here---------------end--------------->8---
>> > Is the above supposed to work in any Emacs source tree? Also, what
>> > should be the default-directory in step 1 (if it's important) --
>> > should it be the root of the Emacs source tree?
>>
>> That shouldn't matter, I think, as long as you have several files with
>> "mini" in their names in the cache.
>
> If I invoke 'find' from the shell prompt, I get this:
>
> D:\gnu\git\emacs\branch>find . -name "mini*"
> ./doc/emacs/mini.texi
> ./doc/lispref/minibuf.texi
> ./lib/mini-gmp-gnulib.c
> ./lib/mini-gmp.c
> ./lib/mini-gmp.h
> ./lisp/minibuf-eldef.el
> ./lisp/minibuf-eldef.elc
> ./lisp/minibuffer.el
> ./lisp/minibuffer.elc
> ./src/deps/minibuf.d
> ./src/minibuf.c
> ./src/minibuf.o
> ./test/lisp/minibuffer-resources
> ./test/lisp/minibuffer-resources/data/minibuffer-test-cttq$tion
> ./test/lisp/minibuffer-tests.el
> ./test/lisp/minibuffer-tests.elc
> ./test/src/minibuf-tests.el
>
> Do you get something very different?
No, I get more or less the same.
Instead of using `file-cache-add-directory-using-find`, you can also set
`file-cache-alist` directly:
--8<---------------cut here---------------start------------->8---
(setq file-cache-alist
'(("bar" "/foo")
("baz" "/foo")
("bad" "/foo")
("bay" "/foo")
("ban" "/foo")))
--8<---------------cut here---------------end--------------->8---
Then `C-x C-f ba C-TAB M-<down> M-<down> ...` should show the issue.
Earlier I wrote that the same issue appears in Emacs 29.1, but now I
tested that again and I think I might have been mistaken. In Emacs 29.1
I see a different issue: `M-<down>` in the above recipe emits an error:
--8<---------------cut here---------------start------------->8---
Wrong type argument: number-or-marker-p, ""
--8<---------------cut here---------------end--------------->8---
and doesn't change the minibuffer contents.
Thanks,
Eshel
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 16:51:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 68022 <at> debbugs.gnu.org (full text, mbox):
> From: Eshel Yaron <me <at> eshelyaron.com>
> Cc: 68022 <at> debbugs.gnu.org
> Date: Mon, 25 Dec 2023 16:41:27 +0100
>
> Instead of using `file-cache-add-directory-using-find`, you can also set
> `file-cache-alist` directly:
>
> --8<---------------cut here---------------start------------->8---
> (setq file-cache-alist
> '(("bar" "/foo")
> ("baz" "/foo")
> ("bad" "/foo")
> ("bay" "/foo")
> ("ban" "/foo")))
> --8<---------------cut here---------------end--------------->8---
>
> Then `C-x C-f ba C-TAB M-<down> M-<down> ...` should show the issue.
>
> Earlier I wrote that the same issue appears in Emacs 29.1, but now I
> tested that again and I think I might have been mistaken. In Emacs 29.1
> I see a different issue: `M-<down>` in the above recipe emits an error:
>
> --8<---------------cut here---------------start------------->8---
> Wrong type argument: number-or-marker-p, ""
> --8<---------------cut here---------------end--------------->8---
>
> and doesn't change the minibuffer contents.
That's what I see in Emacs 29. So are we talking about one problem or
two different problems?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#68022
; Package
emacs
.
(Mon, 25 Dec 2023 17:36:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 68022 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Cc: 68022 <at> debbugs.gnu.org
>> Date: Mon, 25 Dec 2023 16:41:27 +0100
>>
>> Instead of using `file-cache-add-directory-using-find`, you can also set
>> `file-cache-alist` directly:
>>
>> --8<---------------cut here---------------start------------->8---
>> (setq file-cache-alist
>> '(("bar" "/foo")
>> ("baz" "/foo")
>> ("bad" "/foo")
>> ("bay" "/foo")
>> ("ban" "/foo")))
>> --8<---------------cut here---------------end--------------->8---
>>
>> Then `C-x C-f ba C-TAB M-<down> M-<down> ...` should show the issue.
>>
>> Earlier I wrote that the same issue appears in Emacs 29.1, but now I
>> tested that again and I think I might have been mistaken. In Emacs 29.1
>> I see a different issue: `M-<down>` in the above recipe emits an error:
>>
>> --8<---------------cut here---------------start------------->8---
>> Wrong type argument: number-or-marker-p, ""
>> --8<---------------cut here---------------end--------------->8---
>>
>> and doesn't change the minibuffer contents.
>
> That's what I see in Emacs 29. So are we talking about one problem or
> two different problems?
Well, the same interaction yields two different unexpected results
depending on which Emacs you're running: in Emacs 29.1 we get an error,
and on master each completion candidate is appended to the previous one
in the minibuffer instead of replacing it. In both cases, it seems that
`M-<down>` doesn't do the right thing when the *Completions* buffer is
showing file cache completions.
This bug report was last modified 1 year and 179 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.