bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

> You're barking at the wrong tree.  That code worked well for half of its
> lifetime.  What really got us into the present bredouille was commit
> 6355802033d202c63f6fff4b77bf2b0c7aecceef and its ill-fated decision to
> call Fselect_window instead of directly setting selected frame and
> window as the well-established and tested code in display_mode_lines
> did and still does.

In case you intend to fix this apparent blunder of mine: the point of
that commit was to set the selected window and frame so that ELisp code
run from the `mode-line-format` would see meaningful and consistent
values of selected-frame/window (and companions like the
frame-selected-window of the selected-frame, ...).

If calling `Fselect_window` with a non-nil `norecord` argument messes
things up somehow then maybe we should fix `Fselect_window` accordingly,
or otherwise provide a "more bare bones" function that DTRT.

It seems clear to me, for example, that when called with a non-nil
`norecord` (like in the mode-line code), `Fselect_window` should never
cause any change to the focus redirection (or the focus itself).
And neither should it call things like `resize_mini_window`, I think.

> In the sequel, obscure bugs began to pile up, all very difficult to
> describe and reproduce (Bug#23124, Bug#24285, Bug#34317) and were fixed
> with some trickery.  The origin of all that evil remained in place.

I can't see the connection between these bugs at the above commit, sorry.


        Stefan