GNU bug report logs - #56305
29.0.50; 'yes-or-no-p' deselects minibuffer frame

Previous Next

Full log

Message #53 received at 56305 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 56305 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
 acm <at> muc.de
Subject: Re: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Tue, 5 Jul 2022 17:09:48 +0000

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 <at> gmx.at, monnier <at> iro.umontreal.ca, 56305 <at> debbugs.gnu.org
> > From: Alan Mackenzie <acm <at> 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).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.