Subject: Re: bug#77649: [PATCH] Add support for updating *Completions* as you type

From: Spencer Baugh <[email-masked]>
Date: Tue, 08 Apr 2025 15:00:35 -0400

Juri Linkov <[email-masked]> writes:

>> Add support for updating the *Completions* buffer as you type,
>> controlled by a new completion metadata symbol 'eager-update and
>> new defcustom completion-eager-update.
>>
>> You can configure a completion category to update *Completions*
>> as you type by setting completion-category-overrides
>> appropriately; or set completion-eager-update to t to always
>> update *Completions* as you type.
>>
>> This is similar to the recently added completion-eager-display.
>
> Thanks, now finally we'll have this long-needed feature.

Indeed.  BTW, I should have mentioned in my first email that this
depends, for performance, on the new lazy-inserting-into-*Completions*
functionality I added; that makes performance good even when there are
many completions.

> The first question: should it depend on the value of
> 'minibuffer-visible-completions'?  OTOH, even when it's nil,
> *Completions* can be displayed by non-nil completion-eager-display.

Right, or of course the user could just explicitly hit ? to display
*Completions*.  So I don't currently see a reason why we'd depend on
minibuffer-visible-completions.

> So the only problem is that when the *Completions* window is removed
> (e.g. when no candidates remains), it never comes back to the display
> (e.g. after deleting previous characters).
>
> Or maybe this is not a problem, I have to test it more.

The specific scenario of *Completions* disappearing when no candidates
remain has not been a problem for me.

But it is possible that we want to make other changes in this area
(maybe separate from this patch?)  *Completions* can be hidden for many
reasons, but maybe when eager-display behavior is enabled, *Completions*
should not be hidden as readily?  Maybe eager-display should cause the
behavior to be more like completion-auto-help=visible?