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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: rudalics <at> gmx.at, Eli Zaretskii <eliz <at> gnu.org>, 56305 <at> debbugs.gnu.org
Subject: Re: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
Date: Wed, 06 Jul 2022 14:34:39 -0400

>> > > Do you have a suggestion for a change there to improve the behavior?
>> > I do now.  I think we should expunge the entire section of code.

FWIW, I totally agree.  I'm far from sure that the result will be what
we want, but I think that in case it's not we will then know better what
it is that we want and we'll be in a better position to find
a good solution.

>> I guess that means Emacs 28.2 will have this issue unresolved, unless
>> someone comes up with some ideas.
> An idea I had on Sunday was to forcibly set the window system focus to
> the minibuffer frame just before the recursive edit in read_minibuf,
> though I didn't post a patch for it.  This appears to work for me.

Not sure if "Fx_focus_frame (mini_frame, Qt)" is The Right solution
in the sense that it may fail to correctly set the accompanying
redirection from the "original" frame.

But it seems like a good stop-gap for `emacs-28`, yes.  I'd recommend we
try not to use it in `master` (where we could instead check that the
mini_frame has the focus and drop into the debugger if not to try and
figure out what can cause such a situation).


        Stefan

Previous Next

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