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 18:25:23 +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=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20431"; 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 19:26:49 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 1kyfQO-0005DI-Go for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Jan 2021 19:26:48 +0100 Original-Received: from localhost ([::1]:54522 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kyfQN-0005AA-HU for ged-emacs-devel@m.gmane-mx.org; Sun, 10 Jan 2021 13:26:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kyfP7-0004ba-Dq for emacs-devel@gnu.org; Sun, 10 Jan 2021 13:25:29 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:49220 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kyfP5-00061G-0K for emacs-devel@gnu.org; Sun, 10 Jan 2021 13:25:29 -0500 Original-Received: (qmail 62369 invoked by uid 3782); 10 Jan 2021 18:25:25 -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 19:25:23 +0100 Original-Received: (qmail 21685 invoked by uid 1000); 10 Jan 2021 18:25:23 -0000 Content-Disposition: inline In-Reply-To: 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:262872 Archived-At: Hello, Martin. On Sun, Jan 10, 2021 at 18:49:03 +0100, martin rudalics wrote: > > 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. > This "MOVES THE FOCUS TO THAT FRAME" is done by the WM. Emacs doesn't > care normally because it usually can't fight it anyway (you can try by > setting the ‘no-focus-on-map’ frame parameter but it's no general cure). > With practically all WMs, a new window always gets focus automatically. > > Why shouldn't that be done in the current scenario? > Because we are talking about a frame (F2) that already exists in your > scenario. Sorry, that answer doesn't fit the question I though I was asking. What I meant was that it is surely a good thing that after visiting a file with C-x C-f, the focus ends up in the frame where the file's buffer is. Why does this cease to be a good thing if the frame already exists? Note other scenarios where the frame already exists, such as C-x 5 b foo.el RET when foo.el is already displayed in another frame. The focus is moved to that other frame. Whether that is done by Emacs or the WM is immaterial, the focus MUST be moved, otherwise there'd be no point to doing the C-x 5 b. Similarly with a "deferred" C-x C-f, the focus must also be moved. Surely? I'll need to go back a bit to try and understand the arguments against shifting the focus. Right at the moment, I'm not seeing them. > martin -- Alan Mackenzie (Nuremberg, Germany).