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

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 05, 2022 at 05:29:21 +0300, Eli Zaretskii wrote:
> > 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.

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.

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

See above.

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

You might, yes.  But I think the irritation in having to switch frames to
NF to look at the long list will be outweighed by the opposite irritation
of always having to switch frames to MBF to answer "yes" or "no".

-- 
Alan Mackenzie (Nuremberg, Germany).