GNU bug report logs - #78944
31.0.50; Minibuffer completion

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: 78944 <at> debbugs.gnu.org
Cc: eliz <at> gnu.org, monnier <at> iro.umontreal.ca, dmoncayo <at> gmail.com
Subject: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 00:29:46 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Dani Moncayo [2025-07-19 09:47:31] wrote:
>
>> On Sat, Jul 19, 2025 at 9:03 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>> [...]
>>>
>>> Ping!  How should we make some progress with this issue?
>>
>> FWIW: I don't see a good solution for this (minor) issue.  But I'd
>> like to say that I'd rather not complicate the (already complex) logic
>> for minibuffer completion.
>
> Maybe the patch below?  It doesn't actually fix the problem, but with
> Dani's recipe it adds a message
>
>     Switched from style ‘partial-completion’ back to ‘basic’
>
> at the end of the minibuffer, to try and explain what's going on.

Could we please avoid adding side-effects like message printing to the
functions `completion-all-completions`, `completion-try-completion' and
the underlying `completion--nth-completion`? I'd lean to not adding
complications, or side-effects to this API. Messages are better printed
on a higher level, on the level of completion commands. In case the
message is really needed at least guard it behind an option?

Daniel

Previous Next

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