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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Tue, Jul 05, 2022 at 19:24:02 +0300, Eli Zaretskii wrote:
> > Date: Tue, 5 Jul 2022 15:59:00 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > After typing C-x C-c, rather than exiting, this particular Emacs
> > > > prompts:

> > > >     "Active processes exist; kill them and exit anyway? (yes or no) "

> > > > on MBF and it opens a window *Process List* on NF.

> > > Sounds right to me: the frame where Emacs presents some important
> > > information has focus.  If you think this is wrong, please tell why.

> > Well, I don't have a firm opinion on this, but yes-or-no-p is an active
> > function, here.  We always leave the minibuffer as the selected window
> > for this function, certainly when we've a normal minibuffer in the frame.
> > Why should it be different when we've got a minibuffer-only frame?

> > Also, the mechanism by which NF gets the focus in the bug scenario
> > appears to be random.  When the focus starts out in NF and we do C-x C-c,
> > the focus moves to MBF.  This is inconsistent.

> > The place where the randomness takes effect is the 

> >     Fredirect_frame_focus (gfocus, frame);

> > in do_switch_frame I drew attention to yesterday.

> Do you have a suggestion for a change there to improve the behavior?

As yet, no.  I am still having trouble understanding the code well
enough.

But there's at least one interesting aspect.  In the Elisp manual page
"Input Focus" appears the following:

       Lisp programs can switch frames temporarily by calling the function
    `select-frame'.  This does not alter the window system's concept of
    focus; rather, it escapes from the window manager's control until that
    control is somehow reasserted.

This is sadly not true - the functions called by that
Fredirect_frame_focus in do_switch_frame do indeed change the window
system's focus - in particular x_frame_rehighlight (in xterm.c).  If we
were to change the code rather than the manual here, I think a fair bit
of confusion would vanish.  But this isn't something for the release
branch.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).