From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Sun, 10 Jul 2022 11:34:50 +0000 Message-ID: References: <83zghm5evt.fsf@gnu.org> <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26023"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56305@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca, acm@muc.de To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 10 13:35:16 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oAVDW-0006Wn-L0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 13:35:14 +0200 Original-Received: from localhost ([::1]:41854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oAVDV-0000kW-7s for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 07:35:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35084) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oAVDK-0000h1-MC for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 07:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42466) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oAVDK-0001wg-Ef for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 07:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oAVDK-00033j-9m for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 07:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2022 11:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56305 X-GNU-PR-Package: emacs Original-Received: via spool by 56305-submit@debbugs.gnu.org id=B56305.165745290011746 (code B ref 56305); Sun, 10 Jul 2022 11:35:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 10 Jul 2022 11:35:00 +0000 Original-Received: from localhost ([127.0.0.1]:36363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oAVDI-00033O-7u for submit@debbugs.gnu.org; Sun, 10 Jul 2022 07:35:00 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:14115 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1oAVDF-00033B-QH for 56305@debbugs.gnu.org; Sun, 10 Jul 2022 07:34:58 -0400 Original-Received: (qmail 21506 invoked by uid 3782); 10 Jul 2022 11:34:51 -0000 Original-Received: from acm.muc.de (p4fe15b15.dip0.t-ipconnect.de [79.225.91.21]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Jul 2022 13:34:51 +0200 Original-Received: (qmail 5953 invoked by uid 1000); 10 Jul 2022 11:34:50 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:236561 Archived-At: Hello, Martin. On Sun, Jul 10, 2022 at 10:07:28 +0200, martin rudalics wrote: > > diff --git a/src/minibuf.c b/src/minibuf.c > > index 0fc7f2caa1..0d80b2ec90 100644 > > --- a/src/minibuf.c > > +++ b/src/minibuf.c > > @@ -896,6 +896,16 @@ 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. Don't give that frame the focus if it's > > + already got it, since this might cause the frame to be wrongly > > + raised. */ > > + if (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame > > + && (FRAME_DISPLAY_INFO (XFRAME (mini_frame))->x_focus_frame > > + != XFRAME (mini_frame))) > > + Fx_focus_frame (mini_frame, Qt); > > + > > recursive_edit_1 (); > > /* If cursor is on the minibuffer line, > > How do you react to this suggestion? Anyhow, I just tried it on a Linux > > tty, and it segfaults. ;-( So it clearly needs some refinement. > This doesn't improve anything here. On Debian I'm using a setup which > is described under "Focus Settings" here > https://docs.xfce.org/xfce/xfwm4/4.12/preferences Thanks! I use xfce, too. But I haven't changed anything here away from its default. I run Emacs on a tty anyway. > In particular, I (a) Automatically raise windows when they receive focus > and I use a (b) Delay before raising focused window. (a) is for me > indispensable to bring a window to foreground with the mouse (mainly due > to a habit developed while working under Windows where clicking into a > lowered frame to raise it inevitably moved point in the Emacs window > clicked at). (b) is indispensable to avoid that some arbitrary window > gets raised when moving the mouse over it while trying to reach some > specific window (this is one case mutter handles decidedly better than > xfwm). If anybody can suggest a better setup for emulating what Emacs > calls 'mouse-autoselect-window' on the display level, I'll be all ears. > Now note that when in my scenario I type C-x C-c, the minibuffer frame > is selected and has focus. But not raised, though? Surely the MB frame being selected and having focus is what we want, so that we can type "yes" or "no" next. > Then apparently the > Fselect_window (old_window, Qt) > call in unwind_format_mode_line (the one you mentioned earlier in this > thread) kicks in causing the window manager to move focus to the normal > frame. (See below.) > Finally, your patch will ask the window manager to focus the > minibuffer frame again and raise it. > I used the term "apparently" because there are too many do_switch_frame > calls triggered by redisplay in order to attribute them orderly to their > precise origin. And tracing focus transitions with GDB is next to > impossible because you continuously have to shift focus between GDB and > the debugged application. Try running GDB in an Emacs on a Linux tty. That's what I do anyway. I seem to remember watching the focus, last time I did this, a day or two ago. Anyway, we'll have to decide soon what to do for Emacs 28.2. The first pretest is already out there. What we do needs to be simple and safe. The alternatives so far seem to be do nothing, apply the 53-line deletion from master (which Eli has already rejected) or apply my patch above (fixed to work with tty's). At the moment, I would favour the last of these. > Nota bene: In each redisplay cycle, Emacs may ask the window manager at > least twice for each of its frames to refocus it in order to format that > frame's title. Doesn't a window manager have better things to do than > cater for how applications try to format their internal data? Doesn't > such an interaction strike anyone as provocative at least? select-window and select-frame should NOT move the focus. select-frame is even documented (in the Elisp manual) not to do this. That documentation is not true for Emacs 28.x, but may now have become true in master since I removed those 53 lines from do_switch_frame, but I'm not sure. A worthwhile project would be rigourously to determine where the focus gets changed as a side effect of other things and to remove such side effects. Then we could add code to move the focus when we actually want to. > > I suggested using s-f-s-input-focus at one time, but you pointed out > > that this would raise the frame, which isn't wanted. > s-f-s-input-focus would add insult to injury - guaranteeing an unwanted > raise even if 'x-focus-frame' alone would not raise it. > > But surely every window manager will give the minibuffer frame the > > focus, precisely what we need here? > I wouldn't even bet on that. Certainly not with newer generations of > window managers. A WM may concede input focus upon an application's > request for special windows like dialog boxes only. We're just lucky if > it allows to give focus to some "normal" window too. You're implying that C-x 5 o might not work with such WMs. That would not be good. > > What could happen with a strange WM > > that could be disturbing? > Isn't that the wrong question? Here we talk about a strange application > that within milliseconds asks the WM to move focus away from one of its > windows and then move it back to the original window in order to format > its internal data. As I said, I don't think select-frame/window should move the focus. Maybe somebody could fix this for Emacs 29. > >> The change to master fixes the bug here. > > Thanks! > Unfortunately, it breaks C-x o. Try with my scenario but instead of > answering the 'yes-or-no-p' question type C-x o. With Emacs 28.1 this > selects the window on top of the normal frame. With current master it > does nothing. I don't think that's true. It selects the other window on the normal frame (which is the selected frame), but retains the focus in the minibuffer frame (the focus being redirected from the normal frame). > It doesn't even tell me that there is no other window to select. So > this cure is certainly worse than the disease. I think that might be over-stating things. Most of the time, users are just going to be typing "yes" or "no" here. > martin -- Alan Mackenzie (Nuremberg, Germany).