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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 4 Jul 2022 19:43:51 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > Quick summary of the problem: On an Emacs with a minibuffer-only frame
> > > (MBF) and a minibuffer-less frame (NF), with MBF selected with focus,
> > > type C-x C-c.  Instead of the focus remaining in MBF, it's moved to NF.
> 
> > I lost you right here: can you explain why what you described isn't
> > TRT?
> 
> 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.

> > I mean, after you typed "C-x C-c", the minibuffer (whether it's a
> > frame or a window) has completed its job, and focus should return to
> > the "real" frame, which is NF.  Right?  What am I missing here?
> 
> After the C-x C-c, and the appearence of the prompt, NF has the focus,
> uselessly, instead of MBF.

How is Emacs supposed to know that the user wants only to _look_ at
the list of processes in this case?  In general, moving focus to where
the information is sounds right to me.

> That means having to do a window-manager
> action to get at the prompt.  This is the bug that Martin registered.

In the scenario you described, I'm not sure it's a bug.  In general,
when Emacs prompts with a question in the minibuffer frame and
displays some information pertaining to the question in another frame,
it is not completely clear where should the focus be.  E.g., suppose
that the list of processes was so long that it wouldn't fit in one
window-full, and you'd need to scroll it to see all of it -- wouldn't
you want then to have the focus in the frame with the process list?