bug#73473: 31.0.50; Minibuffer completions include nonsense prefix candidates

[Eli Zaretskii <eliz@gnu.org>]

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@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.