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>]

> Fselect_frame (or more precisely do_switch_frame) is a place where the
> trouble occurs, or certainly was before my removal of the 53 lines focus
> redirecting/shifting code ~10 days ago.  That removed code seems to be
> needed for correct frame switching with a minibuffer-only frame, but in
> the middle of do_switch_frame doesn't seem to be the optimal place for
> it.

But the interactive calls have nil for `norecord`.

>> 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.
>
> It would be a mistake to couple focus switching with NORECORD, something
> which is only coincidentally tied to the focus.

Currently `norecord` is the flag used to indicate that this is an
"internal" `select-window` call, typically part of something like
`with-selected-window` or `save-window-excursion`, which seem like good
candidates to use the more "bare bones" select-window semantics (whose
difference in semantics I don't fully comprehend, to be honest, so
hopefully, this discussion will lead to doc (or at least comment)
changes to describe those differences).

There might indeed be other calls to `select-window` that specify the
`norecord` arg for some other reason, so maybe linking the two that way
is not a good idea, I don't know.

> Neither can I, but Martin's spent quite a few years analysing these
> things.  The mechanisms of these bugs, and their connection with that
> 2008 patch are likely involved and complicated.

Yes, I didn't mean to say they didn't exist, just that I wasn't able to
see them.

> The current state of affairs is that Emacs 28 is unusable to some
> people who prefer a separate minibuffer frame (in particular, Drew
> Adams) and it may well be worth our while to identify the current bugs
> and fix them.

As you might know, I'm in that same boat :-)


        Stefan