bug#52491: 28.0.90; Regression in window deletion with minibuffer

[Juri Linkov]

> The bug is a regression so it should be fixed.  Whether and how Juri's
> fix can affect other operations that use the minibuffer before deleting
> some window is beyond my imagination.

Maybe it would be possible to change the default behavior of delete-window
to do what it did in Emacs 27?  But honestly, I don't understand how
this old code managed to select the minibuffer after deleting the
completions buffer and why its behavior differs after it was moved to Lisp:

-         /* Now look whether `get-mru-window' gets us something.  */
-         mru_window = call1 (Qget_mru_window, frame);
-         if (WINDOW_LIVE_P (mru_window)
-             && EQ (XWINDOW (mru_window)->frame, frame))
-           new_selected_window = mru_window;
-
-         /* If all ended up well, we now promote the mru window.  */
-         if (EQ (FRAME_SELECTED_WINDOW (f), selected_window))
-           Fselect_window (new_selected_window, Qnil);
-         else
-           fset_selected_window (f, new_selected_window);

> I do not understand two things: It seems that this part of the
> doc-string
>
>   A minibuffer window is never
>   a candidate when MINIBUF is nil or omitted.  MINIBUF t means consider
>   the minibuffer window only if the minibuffer is active.
>
> does not match well this part of the code
>
>     (dolist (window (window-list-1 nil (unless minibuf 'nomini) all-frames))

When MINIBUF is nil, ‘(unless minibuf 'nomini)’ is ‘'nomini’,
when MINIBUF is non-nil, ‘(unless minibuf 'nomini)’ is ‘nil’,
but the third possible value MINIBUF=‘t’ of window-list-1
is not used here.  This value means consider the minibuffer window
even if the minibuffer is not active.  It seems this value is useless
in get-mru-window for the purposes of delete-window?

> And this (are we sure that we always want to do it when "setting up"
> completions?)

Another place would be completion-list-mode, but it's empty.

>       (setq-local delete-window-choose-selected 'mru)
>
> apparently makes this binding
>
>        (choose-selected delete-window-choose-selected)
>
> necessary.  But this would imply that at the time 'delete-window' is
> called, its buffer is current which is by no means guaranteed.  So the
> latter form should probably become
>
>        (choose-selected
>       (buffer-local-value
>        'delete-window-choose-selected (window-buffer window))))

‘buffer-local-value’ would be more correct, thanks.