From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Fri, 27 Nov 2020 16:19:49 +0000 Message-ID: References: <20201123133613.GA4635@ACM> <69ba00e6-b182-77e1-911b-d70f9fffa762@gmx.at> <20201123160703.GB4635@ACM> <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28535"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Alan Mackenzie , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 17:20:56 2020 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 1kigUS-0007Jv-KJ for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 17:20:56 +0100 Original-Received: from localhost ([::1]:55222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kigUR-00080u-Ms for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 11:20:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60948) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kigTg-0007UV-7l for emacs-devel@gnu.org; Fri, 27 Nov 2020 11:20:08 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:51788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kigTe-0000cF-0m; Fri, 27 Nov 2020 11:20:07 -0500 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0ARGJqgS008733 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 16:19:52 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ARGKPTn027803; Fri, 27 Nov 2020 16:20:25 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org 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_PASS=-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:259908 Archived-At: >> With Emacs 28 (-Q), the active minibuffer is moved from frame F1 to >> frame F2 at step (iii), _before_ you answer the C-x 8 RET. That is, the >> active minibuffer is moved from frame F1 to frame F2 whenever you >> switch from frame F1 to frame F2. >> >> With Emacs 21-27, this happens only at step (iv), _after_ you hit C-x 8 >> RET. That is, the active minibuffer is moved from frame F1 to frame F2 >> only when you activate a new minibuffer on frame F2. > > I understand you now. With Emacs 27 the minibuffer window moves lazily > - that is, only when it's needed on some other frame - with Emacs 28 it > moves eagerly. That doesn't look like a change for the better. Alan, > couldn't we try to do that by giving 'minibuffer-follows-selected-frame' > a third value like 'on-demand and move only when the user really wants > to interact with the minibuffer on another frame? > Yes, AFAIU doing this would amount to make it possible to restore the Emacs 21-27 behavior, which would be a good thing. BTW, this (to have three possible behaviors) is what I suggested as early as Oct 14. This suggestion was totally ignored: 1. the Emacs 21-27 behavior, with which all recursive minibuffers are moved from one frame to another when one or more minibuffers are active in one frame, and a new recursive activation happens in another frame: that's what we lost 2. move all recursive minibuffers from one frame to the other when switching to another frame: that's what we now have with minibuffer-follows-selected-frame set to t, except that it doesn't work as it should (the result of the commands do not take place in the frame in which they were initiated) 3. tie each one of the recursive minibuffers to the frame in which it was activated: that's what we now have with minibuffer-follows-selected-frame set to nil, except that it doesn't work as it should (interacting with the minibuffers that are not the most recently entered one break things badly) My feeling (I did not look at the code) is that too many things were changed at once. Perhaps this should be done / have been done in two steps, first implement the additional behavior 2, then behavior 3.