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

>> 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, ...).
> How are display_mode_line or display_mode_lines affected by that commit?

I'm sorry, I don't understand the question.

> Worse even: People who want to know, for example, whether the mode line
> belongs to the selected window have to use 'old-selected-window' for
> getting that.

Not sure "worse" than what.

Clearly when computing the mode-line, there are 2 windows of interest:
the one to which this mode-line belongs and the one that's currently
considered (from the outside) as "the selected window".  Only one of the
two can be "the selected window" while computing the mode-line, and in
my experience most code wants/needs this to be the mode-line's window
rather than "the one that's currently considered (from the outside) as
the selected window".

> And by no means I'd ask for changing this.  But a better explanation in
> the doc-strings and the manual should be in order.  End of the aside.

I didn't know that `old-selected-window` could be used for that (when
I installed the patch, there was simply no such option and my
recommendation when people needed such a thing was to use
a `pre-redisplay-hook` to set some global var to remember the window
that was selected when entering redisplay).

>> 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).
>
> NORECORD is not about focus.

Then we need something like it but to say "I just want to change
selected-window temporarily, so don't mess with focus or any such thing".

Or maybe, an alternative would be to wait until the next redisplay to
reflect the effect of select-frame/window on focus.

>> I can't see the connection between these bugs at the above commit, sorry.
> They are a direct result of x/gui_consider_frame_title calling
> Fselect_window calling resize_mini_window and were fixed by binding
> 'inhibit-redisplay' appropriately in x/gui_consider_frame_title.

Hmm... following the idea above, maybe select-frame/window should never
call resize_mini_window, and instead that should only take place at the
next redisplay.


        Stefan