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

[martin rudalics]

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