bug#74019: [PATCH] Optionally preserve selected candidate across *Completions* update

[Spencer Baugh]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Shouldn't we stop complicating the completion machinery at some point?
>
> Complexity knows no bounds.
>
> OT1H I agree that the completion infrastructure would benefit from some
> cleanup and is too complex in some areas.  OTOH this specific request
> doesn't affect the "completion machinery", but only the
> `minibuffer-completion-help` functionality which is a fairly simple part
> of the code.
>
>> what's going on is to step with a debugger through the code -- and it
>> doesn't help that some of the code is in Lisp and some in C, so Lisp
>> calls into C, which calls back into Lisp, etc., thus one needs to
>> interrupt the stepping, fire up a different debugger, then go back.
>
> I luckily haven't had to step through the C code of the completion in
> a long while.  But the code layout could be improved to better reflect
> the architecture of the system (the separation between the "backend"
> (completion tables), the "middle end" (completion styles), the standard
> minibuffer UI, the in-buffer UI, the completion-list-mode).

Since pretty much everything completion related is in minibuffer.el, I
wonder if it would be useful to introduce a file separate from
minibuffer.el for things which *aren't* related to completion?  There
are a few of those things in minibuffer.el, and it might help to
maintain a stricter separation.

And as I mentioned elsewhere, maybe we could move completion-list-mode
into minibuffer.el?

Then we could be very clear in the commentary of minibuffer.el that
despite its name, it is the file where all the completion machinery
lives, in or out of the minibuffer.

(It would be really nice to be able to just eval minibuffer.el to pick
up changes to completion, instead of also having to eval simple.el...)

>> Stefan, WDYT?  Should we close completion to further development and
>> accept only bugfixes?
>
> 🙂
>
>
>         Stefan