bug#48356: 28.0.50; choose-completion discards the suffix after the completion boundary

[Dmitry Gutov <dmitry@gutov.dev>]

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.