unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
@ 2023-12-25  6:54 Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-12-25 12:44 ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-25  6:54 UTC (permalink / raw)
  To: 68022


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





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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25  6:54 bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-12-25 12:44 ` Eli Zaretskii
  2023-12-25 13:47   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2023-12-25 12:44 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 68022

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





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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25 12:44 ` Eli Zaretskii
@ 2023-12-25 13:47   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-12-25 15:05     ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-25 13:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 68022

Eli Zaretskii <eliz@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.







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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25 13:47   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-12-25 15:05     ` Eli Zaretskii
  2023-12-25 15:41       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2023-12-25 15:05 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 68022

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 68022@debbugs.gnu.org
> Date: Mon, 25 Dec 2023 14:47:52 +0100
> 
> Eli Zaretskii <eliz@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?





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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25 15:05     ` Eli Zaretskii
@ 2023-12-25 15:41       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2023-12-25 16:50         ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-25 15:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 68022

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 68022@debbugs.gnu.org
>> Date: Mon, 25 Dec 2023 14:47:52 +0100
>>
>> Eli Zaretskii <eliz@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





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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25 15:41       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2023-12-25 16:50         ` Eli Zaretskii
  2023-12-25 17:35           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2023-12-25 16:50 UTC (permalink / raw)
  To: Eshel Yaron; +Cc: 68022

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 68022@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?





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

* bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input
  2023-12-25 16:50         ` Eli Zaretskii
@ 2023-12-25 17:35           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 7+ messages in thread
From: Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2023-12-25 17:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 68022

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: 68022@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.





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

end of thread, other threads:[~2023-12-25 17:35 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-25  6:54 bug#68022: 30.0.50; File cache completions accumulate instead of replacing minibuffer input Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-25 12:44 ` Eli Zaretskii
2023-12-25 13:47   ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-25 15:05     ` Eli Zaretskii
2023-12-25 15:41       ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-25 16:50         ` Eli Zaretskii
2023-12-25 17:35           ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors

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