GNU bug report logs - #73473
31.0.50; Minibuffer completions include nonsense prefix candidates

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jordan Ellis Coppard <jc+o.emacs <at> wz.ht>
Cc: 73473 <at> debbugs.gnu.org
Subject: bug#73473: 31.0.50; Minibuffer completions include nonsense prefix candidates
Date: Fri, 27 Sep 2024 11:12:01 -0400

>> I've noticed that my completions have slowed down A LOT on recent Emacs
>> builds, it turns out nonsense completion candidates (which I am calling
>> "prefix candidates") are being included as... completion candidates.
[...]
>> To reproduce, using `emacs -Q` of course:
>>
>> 1. Open Emacs.
>> 2. C-h o foo TAB
[...]
>> If I do the same on the currently released Emacs or another (older)
>> build of Emacs (30.0.50) there are 79 (not 80) completion candidates and
>> `footnote-` is not listed as one.

This was done on-purpose: the `footnote-` prefix is included as a "stand
in" for the not-yet-loaded definitions of `footnote.el`.  The idea is
that if you're looking for, say, `PREFIX-SUFFIX` in package PREFIX you
can get there by doing

    C-h o PREF TAB

which completes to `PREFIX-`, and then

    SUF TAB

(which now works because `PREFIX.el` was loaded under the hood).

AFAICT, there is a performance bug here in that just doing the
`C-h o PREF TAB` which completes to `PREFIX-` already loads `PREFIX.el`
which is a bit over-enthusiatic (I intended it to load `PREFIX.el`
only when you hit TAB while you already have `PREFIX-` in your
minibuffer).

>> This seems to be occurring for almost every unique prefix possible, 
>> compounding as time goes on. So later on `f-` is listed as a completion 
>> candidate, then also `go-` and so on. These are not valid completion 
>> candidates. `footnote-` is not a symbol. Over time the huge increase in 
>> completion candidate volume (and perhaps what is causing this behind the 
>> scenes) results in such a slowdown that I can visibly see Emacs crawl to 
>> 1 FPS when I type in minibuffer completion, when the exact same init.el 
>> on said older 30.0.50 is faster.

It's probably not directly linked to the number of symbols defined, but
rather to side-effects introduced by some of the packages that were
loaded (which I'd argue are probably themselves (performance) bugs in
those packages).


        Stefan

Previous Next

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