|
From: | Dmitry Gutov |
Subject: | bug#48356: 28.0.50; choose-completion discards the suffix after the completion boundary |
Date: | Mon, 15 Apr 2024 02:55:35 +0300 |
User-agent: | Mozilla Thunderbird |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |