From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#56305: 29.0.50; 'yes-or-no-p' deselects minibuffer frame Date: Sun, 10 Jul 2022 10:07:28 +0200 Message-ID: References: <83zghn7ckd.fsf@gnu.org> <83zghm5evt.fsf@gnu.org> <5d86d890-9a2e-e4d6-13fb-da03285ea003@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2508"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 56305@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 10 10:08:21 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 1oARzI-0000Ub-I2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 10:08:20 +0200 Original-Received: from localhost ([::1]:58116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oARzH-0001cf-1r for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Jul 2022 04:08:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58920) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oARz0-0001bm-V5 for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 04:08:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42318) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oARz0-0003Hu-KU for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 04:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oARz0-0001fZ-Fx for bug-gnu-emacs@gnu.org; Sun, 10 Jul 2022 04:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Jul 2022 08:08: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.16574404656388 (code B ref 56305); Sun, 10 Jul 2022 08:08:02 +0000 Original-Received: (at 56305) by debbugs.gnu.org; 10 Jul 2022 08:07:45 +0000 Original-Received: from localhost ([127.0.0.1]:36215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oARyi-0001et-OO for submit@debbugs.gnu.org; Sun, 10 Jul 2022 04:07:45 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:45543) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oARyg-0001eg-98 for 56305@debbugs.gnu.org; Sun, 10 Jul 2022 04:07:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657440450; bh=xUE7KiAyU07SR6+61dNLrpmu4NfzlMrtaNC7WCg+0bY=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=Sm62TCtYPe1W/X9/aMUDPv1pe3PJNP472IVsCXZMBfI6LFN6nTexMJale11+LwzDV Aqph4mZ776PTL/84WNxKf9u8aTF0k1DjXYxqjuF+sX25KEVIxJ2ARXCNJ+vm0hXeOL HolAR3mm4wIgJBISgA0p+tjXwsuQr8T4ShNQ4O4M= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([213.142.97.1]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUGi9-1o1Twf2Tb9-00RIcI; Sun, 10 Jul 2022 10:07:30 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:oD2N4eEJi0/XrgbcvN8ZLCv9hNQAnJNGItypYDqNjf1RSeQbvyl +//4d0op1uDeQpk2QIxdxm5YfD5Vx7nsJ3YGHjuYtAa7kA3OZqgLOe3yAnpxTknfYs7zbar Po4pDOQ6M76223v5GrzWse2o76wSOCUYlvFigu6VVTUmw0QXNUnR7gab0HjBJRisvo61zz1 kE5FdDkkCdUGgEAli7mxw== X-UI-Out-Filterresults: notjunk:1;V03:K0:C+HWFpOgsyA=:U+AlKm8ku695vOM71evEXa HD7qajsnVyGajAqDsmM0DBblNAzoBW50QEUN2WWwLON9U/7QlREWAGibtb8D8iF1mS/70BZK1 WjtQSYIv2k4R4NBH5Egwq3/mohTxNRV1MlV0Y+aCXs6CiqAbFqYogUzX+xp4J3e1pAgqb4YYr tMkYC9nHSsjY6MBE61xGap1/+6fOyJA/KZKTdPIahgnObLwbkSRK1bebnQ7n+4IluoFCLTufi sVHL5RnFa8ia4BFxCnlRXWesVtx5teFAMJ1sOxvyh5/V2OPJpoNh0kV/8P0yLoRr3UrwUCfeB QGtFaQZWj8nKrjx3QTJSTIdYFd+T7Rp56Izdhyq1MfhT7dMX9B0ac82DO6+4cpH4IAqilu/dY mNKP/hVz3IZFxrX36KnALQHlXKSBn10KgUQzinJZ1eusrC+AJOgJzR5cahEyjCafrBicxBmRF mLwnfWVQSDO6Q1U/T+ODmFgvT1TZX19r1qEKqkrPrgz3dZ1gFTTbe5ZU7JYHaVdOMvrPWRiy0 d7QB+teDkLY6ko1xJNnL+jjJEP7k30ybFQ0M1ewqXZLvku3QYZkmcZSkU4BdQ6ZKHd9r7mgYa RUVou9w8BJpYXA8iaiQxhQpyCcOt2AJPvBTaDEpMzgfyBC/heYaMnTUxdYgKkttyZoIsKNtqD lXwmNi63GINUrU2CA6+H+u54hzhHp+6oYueyoXtNbIVnB/RbQUqH4hxm7vwL+WAo+cTqY2wu5 R2gLLYBtA1lkH8USLWVrR051ZcAAx/U79+3R48ypAf/wkY6TFegbBkOeHDioDnbYMK7fN159 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:236543 Archived-At: > 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 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. 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. 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. 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? > 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. > 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. >> 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. It doesn't even tell me that there is no other window to select. So this cure is certainly worse than the disease. martin