GNU bug report logs - #77649
[PATCH] Add support for updating *Completions* as you type

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Tue, 8 Apr 2025 15:18:01 UTC

Severity: normal

Tags: patch

Full log


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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 77649 <at> debbugs.gnu.org
Subject: Re: bug#77649: [PATCH] Add support for updating *Completions* as
 you type
Date: Tue, 08 Apr 2025 15:00:35 -0400
Juri Linkov <juri <at> linkov.net> 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?




This bug report was last modified 68 days ago.

Previous Next


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