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

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Tue, 11 May 2021 17:24:01 UTC

Severity: normal

Found in version 28.0.50

Full log


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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Juri Linkov <juri <at> linkov.net>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, mail <at> daniel-mendler.de,
 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: Mon, 15 Apr 2024 02:55:35 +0300
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.

> 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?

The problem here, from my POV, is that we currently have a solution 
which matches the above goal, but which only makes sense for minibuffer 
(I think you wouldn't store the before/after buffer contents in separate 
string variables the same way). Whereas the API used is the same, so it 
would really make sense to minimize the differences in behavior between 
minibuffer and in-buffer completion.




This bug report was last modified 129 days ago.

Previous Next


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