GNU bug report logs -
#78944
31.0.50; Minibuffer completion
Previous Next
Full log
View this message in rfc822 format
Dani Moncayo [2025-07-03 11:48:30] wrote:
> On Wed, Jul 2, 2025 at 10:15 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>> >> So, why didn't the initial <TAB> pick the only possible completion alternative?
>> Because, between the two don't use the same completion style.
> OK, I understand.
> I'm not sure if/how this behavior could be improved. Perhaps in the
> second <TAB> the completion style should still be the same as the one
> used before.
Yeah, there's probably some way to do that, but it's not completely
clear how (e.g. should we still stick to the "last style" if other
commands were issued between the two completion operations? If so,
which ones should "reset" the styles and which ones shouldn't?).
Maybe a very targeted approach that records the
`completion-try-completion` output (together with the style used), and
then forces the use of the same style when presented with the same input
(i.e. same string and same point position) as the last.
But having different behavior for the same completion input depending on
"how we got there" could be a bit confusing as well.
So maybe instead of forcing the use of the last style when provided with
the same input as the last output and the style is *not* the same as
last time (i.e. in the case that confused you), we could emit a message
saying "switched completion style <FOO> => <BAR>", which could have
saved you the trip to this bug report?
Another option would be to expose the "current style" in the UI
(e.g. with commands to change which style is used).
I think Drew's Icicles takes this approach.
Stefan
This bug report was last modified 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.