GNU bug report logs - #80064
31.0.50; eager-update fails to update, leaving an empty *Completions* buffer

Previous Next

To reply to this bug, email your comments to 80064 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; eager-update fails to update, leaving an empty
 *Completions* buffer
Date: Tue, 23 Dec 2025 18:17:01 +0100

Starting from emacs -Q, execute the following snippet in *scratch*:

(package-initialize)

(setq completions-format 'one-column
      completions-detailed t
      completions-group t
      completion-eager-update t
      completion-eager-display t
      completion-show-help nil
      completion-show-inline-help nil
      minibuffer-visible-completions t
      completion-styles '(substring))

(require 'consult)
(keymap-global-set "M-s l" #'consult-line)

Then open some large Elisp file and press `M-s l`. Enter some word to
search for and then press backspace multiple times, e.g., keep the
backspace key pressed. Then the *Completions* buffer fails to update and
and becomes empty. Entering new input will not lead to further updates.
It seems the problem is that the post-command-hook does not get
installed correctly.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-12-23
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
 'CFLAGS=-O3 -mtune=native -march=native''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 80064 <at> debbugs.gnu.org, 80055 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#80055: [PATCH] eager-display *Completions* again after
 completion failure
Date: Tue, 23 Dec 2025 18:24:02 +0100

Spencer Baugh <sbaugh <at> janestreet.com> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>> Juri Linkov <juri <at> linkov.net> writes:
>>
>>>> If the completion table requests eager-update (so *Completions*
>>>> should be updated as the user types, when already displayed)
>>>> then *Completions* will be dismissed automatically if the user
>>>> types something which isn't a completion.  Previously,
>>>> *Completions* wouldn't be redisplayed until the user requests it
>>>> again.  Now, if the completion table also enables eager-display
>>>> in addition to eager-update, then automatically redisplay
>>>> *Completions* after it disappears.
>>>
>>> Thanks, this is very much needed.  It was too inconvenient
>>> when *Completions* disappeared after typing TAB that completes
>>> to the common prefix of remaining completions.
>>> So I will test the patch for a while.
>>
>> Hello Spencer,
>>
>> Besides this problem, I've observed another issue when I type quickly
>> with eager-update/eager-display. The *Completions* buffer somehow
>> breaks, just displaying an empty buffer. I am testing this with my
>> Consult package, see the commit with
>> eager-update/eager-display/minibuffer-visible-completions support:
>> https://github.com/minad/consult/commit/7be0d6bf556b608b0b38d006a4f66be849d721e0
>>
>> This seems due to the interrupt and an error which disables the PCH?
>>>From that point on the buffer stays empty and I have to restart
>> completion again. Have you observed something like this too? Thanks!
>
> I think I saw something like this once, but only once, ever.  Are you
> consistently getting it?  A config which consistently experiences this
> would be interesting.

The bug appears consistently in a minimal configuration. I created
bug#80064 to track this and I've put you in CC. I could produce it most
easily with Consult, but I've just seen that my recipe also works with
M-x only. The trick is to press backspace to quickly delete input and
this way trigger increasingly expensive candidate computations.

> Also, continuing to type should continue to update *Completions*.  Is
> that not what you were experiencing?  Did it stay permanently blank?

It stays blank. Completion is broken from that point on. I think there
is something wrong with the PCH or it doesn't get installed properly,
maybe due to interrupts. I haven't really looked deeply into this, but I
find the logic a little bit confusing with the mix of
after-change-functions and PCH.

> I didn't do it in this patch, but I think probably eager-update should
> be implemented with an idle timer just like I've done for eager-display.
> Then if the update gets interrupted, it can try again when the user is
> next idle.  That would make the blank buffer go away automatically in
> more cases, when the user is next idle.

Yes, maybe this would fix the problem.

> BTW: I see your config suggests setting completion-show-inline-help=nil
> because otherwise completion has some annoying blocking behavior.  This
> is due to minibuffer-message calling sit-for, and the patch in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79510 will actually fix
> that.  It just needs a NEWS entry; I have it backported to my own site.

Thanks, that's a good improvement.

Daniel

Previous Next

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