[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame
From: |
martin rudalics |
Subject: |
bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame |
Date: |
Sat, 9 Jul 2022 10:35:50 +0200 |
>> It should not deliberately raise a frame that already has focus.
>
> OK. We could add an extra check for the frame already having the focus.
> Is there anything else suboptimal about that proposed fix to emacs-28?
If by "extra check" you mean
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,
then it does not improve anything here - the minibuffer frame is first
lowered and then raised above the normal frame. I do not understand the
idea here anyway. Why give focus to a frame that already has focus?
Why does the comment say "some Emacs frame" while the code checks only
the minibuffer frame?
Recalling my personal experience: I used 'x-focus-frame' in one special
case only - in 'handle-select-window' when 'focus-follows-mouse' is
non-nil. All other calls are via 'select-frame-set-input-focus' where
the intention to _also_ raise the frame is obvious. I would never have
called 'x-focus-frame' from C with the default settings - every second
window manager out there will handle it differently.
> In the mean time, how well does the change to master work? It attempts
> to fix the cause of (rather than just working around) bug #56305.
The change to master fixes the bug here.
martin
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, (continued)
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, martin rudalics, 2022/07/07
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/07
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, martin rudalics, 2022/07/08
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/08
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Eli Zaretskii, 2022/07/08
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/08
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, martin rudalics, 2022/07/09
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Gregory Heytings, 2022/07/08
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame,
martin rudalics <=
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/09
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, martin rudalics, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Eli Zaretskii, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Eli Zaretskii, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Drew Adams, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Alan Mackenzie, 2022/07/10
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, martin rudalics, 2022/07/11
- bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame, Eli Zaretskii, 2022/07/11