GNU bug report logs - #48356
28.0.50; choose-completion discards the suffix after the completion boundary

Previous Next

Full log

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: mail <at> daniel-mendler.de, Juri Linkov <juri <at> linkov.net>,
 48356 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, jdtsmith <at> gmail.com,
 Visuwesh <visuweshm <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#48356: 28.0.50; choose-completion discards the suffix after
 the completion boundary
Date: Thu, 18 Apr 2024 10:25:01 -0400

Dmitry Gutov <dmitry <at> gutov.dev> writes:
> Hi Juri,
>
> On 14/04/2024 19:44, Juri Linkov wrote:
>>> As one downside, it brings back behavior described in
>>> https://debbugs.gnu.org/34517#14. That doesn't seem too critical to me, but
>>> opinions might vary.
>> Sadly, this is quite an important case.  Recently Spencer implemented
>> a way to deselect a candidate in the visible completions list
>> (minibuffer-visible-completions=t) when the user starts typing
>> in the minibuffer.
>
> I think the (admittedly pretty cool) minibuffer-visible-completions
> feature is orthogonal: the scenarios I'm considering and trying to fix
> here also involve selecting a completion from *Completions* in some
> way (e.g. using M-up or M-down followed by M-RET, in default
> configuration). And this is currently working worse for in-buffer
> completion than for minibuffer completion WRT keeping the suffix
> around.

Yes, e.g.:

1. emacs -Q
2. M-x shell
3. mkdir -p dir1 dir2 && touch dir1/foo dir2/foo
4. cat dir/foo TAB
5. *Completions* contains: 2 possible completions: dir1/ dir2/
6. Click "dir1/"
7. The buffer now contains "cat dir1/", the "foo" has been deleted

This is a bug, but moreover it's also inconsistent with minibuffer
completion, e.g.:

8. C-x C-f dir/foo TAB
9. *Completions* contains: 2 possible completions: dir1/ dir2/
10. Click "dir1/"
11. The minibuffer now contains "dir1/foo"

We should make them both behave the same way.

>> But then the user could change the mind
>> and still select a candidate.  This would interfere with the
>> contents of the minibuffer.
>
> Suppose they do. But the list of completions they're shown is for an
> outdated input. Does it really make more sense to erase the current
> input than to insert the completion where it was supposed to go?

Yeah, this patch changes the behavior in the case of an outdated
*Completions* buffer, and the new behavior is buggy, but I think the old
behavior was also buggy and the new behavior is better.

Example: In emacs -Q, if I type

C-x C-f ~/src/emacs/emacs-2 <TAB>

I get completions "emacs-28" and "emacs-29"

Suppose I then type /src (without hitting tab or updating the
*Completions* buffer) so that the minibuffer contains:

~/src/emacs/emacs-2/src

Then I click on one of the completions to choose it.

Before this patch the minibuffer will contain:

~/src/emacs/emacs-28/

and after this patch it will contain

~/src/emacs/emacs-28//src

Both of these are wrong IMO, but IMO the second one is closer to
correct, and it's more consistent with the normal case (when
*Completions* is up to date) and with in-buffer completion behavior, so
I think this patch is an improvement and could be installed.

Still, maybe we can get it to the point where clicking on an outdated
completion makes the minibuffer contain

~/src/emacs/emacs-28/src

instead?  Which I think is the correct behavior.

But I don't think we need to do that before landing this patch.

Previous Next

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