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

[Alan Mackenzie]

Hello, Eli and Martin.

On Wed, Jul 06, 2022 at 20:29:10 +0300, Eli Zaretskii wrote:
> > Date: Wed, 6 Jul 2022 17:04:40 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, 56305@debbugs.gnu.org,
> >   acm@muc.de
> > From: Alan Mackenzie <acm@muc.de>

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

> I'm okay with doing that on master, but who will tell us what will
> that do for Emacs 28?  I hoped to be able to release Emacs 28.2
> soon-ish, so I don't want to wait for this change to collect enough
> trust so that we could cherry-pick it.

I think I will wait a day and see if Martin or Stefan or anybody else
has anything more to say about it.

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

It would look something like this:



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);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,



-- 
Alan Mackenzie (Nuremberg, Germany).