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

[Alan Mackenzie <acm@muc.de>]

Hello, Andreas.

On Wed, Jul 06, 2022 at 21:09:32 +0200, Andreas Schwab wrote:
> On Jul 06 2022, Alan Mackenzie wrote:

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

> Does it?  I don't see why Emacs must be in the foreground when it wants
> to read from the minibuffer.

How about this, then?  It's not perfect, since the test and the focus
setting aren't atomic, but it should work OK at human speeds, shouldn't
it?



diff --git a/src/minibuf.c b/src/minibuf.c
index 0fc7f2caa1..71fd62cede 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -896,6 +896,12 @@ 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);
 
+  /* If some Emacs frame currently has the window-system focus, give
+     it to the minibuffer frame.  This is sometimes needed for
+     minibuffer-only frames.  */
+  if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame)
+    Fx_focus_frame (mini_frame, Qt);
+
   recursive_edit_1 ();
 
   /* If cursor is on the minibuffer line,


> -- 
> Andreas Schwab, schwab@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).