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

[martin rudalics <rudalics@gmx.at>]

 >> But if you display the buffer in a new frame and the window manager
 >> decides to always give focus to a new frame, that window will be
 >> selected.  It took me years to convince Drew that Emacs can't do
 >> anything about that.
 >
 > Odd.  I have no recollection of ever not being
 > convinced that frame operations are often beyond
 > Emacs's control (i.e., that window mgrs rule the
 > roost), or that `display-buffer' isn't, itself,
 > about selecting a window.

Then how about

   This is driving me crazy. I've tried a zillion ways to try to work around
   this problem, to no avail.

   On MS Windows, whenever a new frame is created, it becomes
   "selected"/"focussed". I use quote-marks here, because I think it might be
   more than what Emacs calls frame selection & focus. I admit that it's
   unclear to me just what's going on.

   ...

   I've tried every hack I can think of, from saving and restoring the selected
   buffer/window/frame, to redirecting and un-redirecting the frame focus, to
   playing with before-make-frame-hook and after-make-frame-functions. I cannot
   get the new frame to become un-"selected"/"focussed" and let me continue to
   use the minibuffer for input.

 > As I don't follow commits, could you situate the
 > change you're talking about in terms of a given
 > Emacs release or past discussion (e.g. bug thread)?
 > I'm curious about what got broken when (and why).

The original commit from 2008 can be studied here:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=6355802033d202c63f6fff4b77bf2b0c7aecceef

It was complemented in 2012 by:

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c6bf30222430f41fbb696e296f0f63f465eefc35

I have not tried to find out which one is responsible for the current
behavior nor which release first showed it.  The oldest version I can
build here is Emacs 24.  Neither of these commits hints at a prior bug
or discussion explaining why they were considered necessary.

It's interesting that these commits, while mostly acting on the function
unwind_format_mode_line, do not affect the formatting of mode lines via
display_mode_lines because the part of the vector used by these commits
is always NULL, nil or false there.  Hence the later check

   if (WINDOW_LIVE_P (old_window))

always fails when called from display_mode_line and display_mode_lines
correctly restores old window and frame via restore_selected_window.

Restoring the current buffer could be the only worthy contribution of
these changes but ironically is not done from display_mode_line - the
second argument of format_mode_line_unwind_data being NULL there.

 >> We should eliminate the original sin and be
 >> done with it once and for all.
 >
 > Probably easier said than done?

It's trivial because display_mode_lines handles it correctly.  The only
difficulty is to convince people that the commits mentioned above are
fundamentally flawed.  So far, my explanations have been met with cold
disregard.

martin