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

Previous Next

Full log

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

From: Alan Mackenzie <acm <at> muc.de>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 56305 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Wed, 6 Jul 2022 19:05:44 +0000

Hello, Andreas.

On Wed, Jul 06, 2022 at 20:58:22 +0200, Andreas Schwab wrote:
> On Jul 06 2022, Alan Mackenzie wrote:

> > diff --git a/src/minibuf.c b/src/minibuf.c
> > index 0fc7f2caa1..7723167d4d 100644
> > --- a/src/minibuf.c
> > +++ b/src/minibuf.c
> > @@ -896,6 +896,10 @@ read_minibuf (Lisp_Object map, Lisp_Object initial, Lisp_Object prompt,
> >    /* Don't allow the user to undo past this point.  */
> >    bset_undo_list (current_buffer, Qnil);

> > +  /* Ensure that the minibuffer frame has the window-system focus.
> > +     This is sometimes needed for minibuffer-only frames.  */
> > +  Fx_focus_frame (mini_frame, Qt);

> Can't this steal focus from unrelated windows?

Not obviously.  We're about to run the recursive edit for read_minibuf,
so the frame with the mini-window should have the focus anyway.

The only possibility of theft that I see is if a normal frame already
has its focus redirected to a minibuffer frame.  In that case the normal
frame will lose focus.

I don't think this will happen, or if it does, it won't be serious.

> -- 
> Andreas Schwab, schwab <at> linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

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