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 10:36:35 +0000 Message-ID: References: <53833023-d959-07af-7611-aa2e0bdcc1bc@gmx.at> <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <20201125215450.GC8228@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="30306"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , enometh@meer.net, Stefan Monnier , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 11:37:53 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 1kib8T-0007ls-IY for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 11:37:53 +0100 Original-Received: from localhost ([::1]:37580 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kib8S-0007u0-IP for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 05:37:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kib7T-0007LE-NU for emacs-devel@gnu.org; Fri, 27 Nov 2020 05:36:51 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:60366) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kib7R-0005GR-Pi; Fri, 27 Nov 2020 05:36:51 -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 0ARAac47005589 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 27 Nov 2020 10:36:38 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0ARAbBp9019446; Fri, 27 Nov 2020 10:37:11 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:259863 Archived-At: Hi Alan, >>>>> The behaviour in Emacs 27 is chaotic. Sometimes a minibuffer moves >>>>> with a frame switch, sometimes it doesn't. >>>> >>>> I wouldn't write it is "chaotic". The behavior you consider >>>> "chaotic" is well-defined, and has been there since Emacs 21 at >>>> least: the minibuffer moves from frame F1 to frame F2 if and only if >>>> the minibuffer is active on frame F1 and a recursive minibuffer is >>>> entered on frame F2. >>> >>> I'm not sure what you mean by "is" in that sentence. >> >> I've reread what I wrote five times, and I don't understand the >> question ;-) > > It seems somewhat indefinite _when_ the recursive minibuffer "is" > entered on frame F2, relative to the other operations. > No it is not. Another, perhaps more precise definition would be: in Emacs 21 to 27, when minibuffers MB1 to MBn are active on a frame F1, and an operation which activates the minibuffer is used on a frame F2, the minibuffers MB1 to MBn are moved to frame F2, and the minibuffer MBn+1 is created. >>>> There are other possible behaviors of course, but IMO the current one >>>> is a reasonable one. >>> >>> If a recursive minibuffer operation has been carried out, then the >>> minibuffer moves, if it hasn't it doesn't. That means Emacs has some >>> invisible internal state, something which doesn't seem desirable. >> >> What do you mean? > > In Emacs 27, emacs -Q, C-x 5 2, giving a two-frame setup. In F1, C-x b. > C-x 5 o, moving to F2. C-r SPACE. Note that the open minibuffer > remains on F1. > Yes, this is normal, C-r does not use the minibuffer, but the echo area (you can see this because the cursor does not move leave the buffer in which you are). The minibuffers and echo area are both displayed in the miniwindow, but they are different. > > Now type C-x 8 RET SPACE RET. This sucks the open minibuffer over to > F2, despite the C-r operation having nothing to do with the suspended > operation in the minibuffer. > This is normal again, C-x 8 RET starts an operation which uses the minibuffer, and the cursor leaves the buffer in which you are and moves to the miniwindow. As explained above, when an operation which activates a minibuffer is used on a frame while other minibuffers are active on another frame, they are moved to that frame. I honestly can't see what's wrong with this. IMO the only other reasonable behavior is to make sure that _all_ minibuffers are moved from frame F1 to frame F2 whenever one switches from a frame F1 to a frame F2. This is not feasible with Emacs 21-27, and still not feasible with Emacs 28.