GNU bug report logs - #78944
31.0.50; Minibuffer completion

Previous Next

Full log

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78944 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#78944: 31.0.50; Minibuffer completion
Date: Wed, 23 Jul 2025 09:38:41 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> 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`?
>
> These are supposed to be "pure", indeed, so I agree it's not ideal.
> The information is only available in there and there's no convenient
> "place" to stash that info in the return value.

Some time ago we had discussed an extended API which returns additional
data as part of the return value, which would be an alist. This way,
impure metadata adjustment could be avoided too.

>> I'd lean to not adding complications, or side-effects to this API.
>
> You might be right, but I'm not sure yet.
>
>> Messages are better printed on a higher level, on the level of
>> completion commands.
>
> Clearly, yes, but I don't know how to do that here.

If we are repeatedly hitting the limits of the current API, maybe it is
time to move to an alternative completion backend API which solves the
issues: Extensible return value as alist, generic methods for completion
tables and completion styles, better composition, extensibility for
additional methods like quoting/unquoting, annotations etc which are
part of the metadata right now, ...

>> In case the message is really needed at least guard it behind
>> an option?
>
> Do you have some concrete case where it gets in the way?

I think about places like auto completion where the APIs are called by a
timer or somehow in the back, decoupled from direct user actions. There
are many such uses where purity is assumed and where such a message
rather hurts than helps.

>         Stefan

Previous Next

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