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.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Sun, 10 Jan 2021 17:18:14 +0000 Message-ID: References: <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> <2d91b8cb-0206-32f0-a577-f243fb534aec@gmx.at> <23649b1d-414b-42e7-dbb0-6b63443521ee@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="8424"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 10 18:19:24 2021 Return-path: Envelope-to: ged-emacs-devel@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 1kyeN9-00025K-Jb for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Jan 2021 18:19:23 +0100 Original-Received: from localhost ([::1]:39196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyeN8-0006xv-L6 for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Jan 2021 12:19:22 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyeMA-00066u-FV for emacs-devel@gnu.org; Sun, 10 Jan 2021 12:18:22 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:46392 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kyeM8-0003vH-5i for emacs-devel@gnu.org; Sun, 10 Jan 2021 12:18:22 -0500 Original-Received: (qmail 19691 invoked by uid 3782); 10 Jan 2021 17:18:16 -0000 Original-Received: from acm.muc.de (p4fe15e6c.dip0.t-ipconnect.de [79.225.94.108]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Jan 2021 18:18:14 +0100 Original-Received: (qmail 11929 invoked by uid 1000); 10 Jan 2021 17:18:14 -0000 Content-Disposition: inline In-Reply-To: <23649b1d-414b-42e7-dbb0-6b63443521ee@gmx.at> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262861 Archived-At: Hello, Martin. On Sun, Jan 10, 2021 at 17:04:57 +0100, martin rudalics wrote: > >> It does call 'raise-frame' something people with 'focus-follows-mouse' t > >> (not 'auto-raise') might not want here. And it may have to move the > >> mouse cursor according to the 'mouse-autoselect-window' and > >> 'focus-follows-mouse' policies. Most window managers don't handle the > >> latter well (IIRC only the otherwise abominable mutter and KDE could do > >> it approximately). And the former wants the selected window to be set > >> up well before calling 'select-frame-set-input-focus'. > > It is nevertheless the standard function to call to move focus to a > > different frame. If there are problems with focus-follows-mouse, they > > should surely be fixed in frame.el as a separate problem. > The 'focus-follows-mouse' problem is a window manager problem and cannot > be fixed in frame.el. It typically happens when he mouse pointer is (i) > over frame-1, one (ii) gives focus to frame-2 and (iii) moves the mouse > which causes the WM to refocus frame-1. Some WMs here move the mouse > pointer in (ii) to frame-2 (and forcefully do that for pop up windows) > which can be however a pain for Emacs because the WM doesn't know where > in frame-2 to move it to and so with 'mouse-autoselect-window' a wrong > window may get auto-selected. > And please remain aware of the fact that focus stealing is, in general, > considered bad practice. It shouldn't happen in the case at hand > because _some_ Emacs frame should already have focus when invoking > 'select-frame-set-input-focus'. Still, a window manager's local policy > settings might make it refrain from giving focus to some frame on behalf > of our request. The need to set the focus is as follows. Suppose we replace the select-frame-set-input-focus with the select-frame (actually, do_switch_frame) that was previously there. With minibuffer-follows-selected-frame t (the default), enable-recursive-minibuffers t: Three frames F1, F2, F3: On F1, C-x C-f foo.el. Move to F2: C-x C-f bar.el. Move to F3 C-x C-f baz.el RET. baz.el is visited in F3. The minibuffers remain in F3. Move point to *Minibuf-2* in F3, and type RET. bar.el is visited in F2, BUT THE FOCUS REMAINS IN F3. This is suboptimal. If we visit a file in a frame, the focus should be on that frame, not somewhere else. As an analogy, C-x 5 f foo.el visits foo.el on another (typically new) frame and MOVES THE FOCUS TO THAT FRAME. Why shouldn't that be done in the current scenario? > martin -- Alan Mackenzie (Nuremberg, Germany).