GNU bug report logs - #73092
31.0.50; Completion lists unbound variables with suffix - (e.g., rcirc-)

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jordan Ellis Coppard <jc+o.emacs <at> wz.ht>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 73473 <at> debbugs.gnu.org
Subject: Re: bug#73473: 31.0.50;
 Minibuffer completions include nonsense prefix candidates
Date: Wed, 25 Sep 2024 19:09:31 +0300

merge 73473 72787
thanks

> Date: Wed, 25 Sep 2024 19:54:59 +0900
> From:  Jordan Ellis Coppard via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 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. By 
> my rough estimate this results in about... 10,000 extra completion 
> candidates when invoking `C-h o` (with my personal Emacs configuration).
> 
> To reproduce, using `emacs -Q` of course:
> 
> 1. Open Emacs.
> 2. C-h o foo TAB
> 
> Observe that completion candidate `footnote-` is listed and that there 
> are 80 completion candidates.
> 
> 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 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.
> 
> This is reproduceable on `emacs -Q` as above, (and the useful bug report 
> probably ends right here) but as an aside: my configuration is minimal, 
> my Emacs starts up in about 0.3s and I keep things minimal because I do 
> not want Emacs to ever take longer than instantaneously to respond to 
> keystrokes (if it has to do some long-running job, or something which 
> takes time that's different since feedback that such a thing has kicked 
> off would/should still be instant).

Thanks, this is a known bug#72787.  I hope someone will be able to
look into it soon.

> Tangentially to this, it would be nice if completions could be decoupled 
> from the UI (i.e. they could stream in, with an API to let the user know 
> when the list is complete) because even on 30.0.50 I can often times 
> type faster than completion can handle which drives me insane (UI 
> hitching)... but that's an aside.

Please file a separate feature request for this, if you think we
should change the design so radically.

Previous Next

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