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: Fri, 27 Nov 2020 11:14:58 +0000 Message-ID: References: <0d14bfc4-8e8e-d3b9-e0e1-ee4bf2e6449d@gmx.at> <20201125210947.GB8228@ACM> <20201125215450.GC8228@ACM> 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="37039"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, martin rudalics , enometh@meer.net, Stefan Monnier , Eli Zaretskii To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Nov 27 12:15:45 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 1kibj5-0009WT-Ve for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 12:15:43 +0100 Original-Received: from localhost ([::1]:44998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kibj5-0000CE-0R for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Nov 2020 06:15:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kibiT-000886-Lu for emacs-devel@gnu.org; Fri, 27 Nov 2020 06:15:05 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10048 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kibiQ-00022k-1X for emacs-devel@gnu.org; Fri, 27 Nov 2020 06:15:05 -0500 Original-Received: (qmail 97143 invoked by uid 3782); 27 Nov 2020 11:14:59 -0000 Original-Received: from acm.muc.de (p4fe15c16.dip0.t-ipconnect.de [79.225.92.22]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Fri, 27 Nov 2020 12:14:58 +0100 Original-Received: (qmail 6010 invoked by uid 1000); 27 Nov 2020 11:14:58 -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=unavailable 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:259869 Archived-At: Hello, Gregory. On Fri, Nov 27, 2020 at 10:36:35 +0000, Gregory Heytings wrote: > Hi Alan, > >>>>> The behaviour in Emacs 27 is chaotic. Sometimes a minibuffer moves > >>>>> with a frame switch, sometimes it doesn't. [ .... ] > >>> 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. I can see a lot wrong with it, from a UI point of view. Whether the MB gets moved depends on _how_ a user enters characters into C-r. This is bad. The MB should either move when you type C-r or it shouldn't. Emacs 28 fixes this. Also we shouldn't force users to have to understand the difference between the echo area and the minibuffer. Some of them will understand, many will not. That most of isearch uses the echo area, but some of it uses the minibuffer, is an arcane implementation issue which users shouldn't have to worry about. We should leave them in peace. > 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. As you note in your next post, it is feasible with Emacs 28, or at least will be when the bugs are fixed. -- Alan Mackenzie (Nuremberg, Germany).