bug#45072: 28.0.50; Emacs switches other buffer back uncontrollably, if other window's buffer is changed by user during minibuffer editing

[martin rudalics]

> What do you think about let-binding a new variable
> read-minibuffer-record-windows to nil around functions
> that pop up completion windows?
>
> I mean for example in minibuffer-completion-help:
>
>    (let ((read-minibuffer-record-windows nil))
>      (display-completion-list completions))
>
> The default value of read-minibuffer-record-windows could be t,
> so it will record new windows created by the user, e.g. by C-x 2.
> But when let-bound to nil, it won't record windows created
> by completion commands, so these windows won't be restored
> after exiting the minibuffer.

We'd have to augment the 'quit-restore' mechanism somehow and run it on
all windows instead of restoring the configuration.

But I still don't understand the logic of the following:

(1) Start minibuffer interaction, type a-

(2) Pop up a completion window for a- and accept suggestion a-b

(3) Type another - so you now get a-b-

(4) Pop up a completion window for a-b- and accept a-b-c

In this scenario I'd want, after accepting a-b, the completion window to
disappear (or show its old buffer again) without the minibuffer action
having terminated.  So I'm still convinced that restoring a previous
state should be triggered by the completion mechanism and not by the
read from minibuffer mechanism.

One thing that has to be considered too is user interaction during
completion: Suppose I have one window, the completion mechanism pops up
a new one and I delete the old one.  Terminating completion now cannot
delete the new window (especially if it's on the only frame in use) but
has to show another buffer in the new window.  It maybe should try to
show the one previously shown in the old window.

And let's not forget that the completion mechanism might pop up a new
frame or a window on any other frame.  In such case, restoring window
configurations won't help at all.

martin