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

Previous Next

Full log

View this message in rfc822 format

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

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

Previous Next

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