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: Wed, 14 Oct 2020 18:45:23 +0000 Message-ID: <20201014184523.GC7651@ACM> References: <20201013190255.GA8896@ACM> <838sca0w7k.fsf@gnu.org> <20201013195103.GB8896@ACM> <20201013204408.GC8896@ACM> <831ri027vz.fsf@gnu.org> <20201014160240.GA7651@ACM> <83d01kzswk.fsf@gnu.org> <20201014163534.GB7651@ACM> <838sc8zqjj.fsf@gnu.org> 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="11101"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ghe@sdf.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 20:46:32 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 1kSlnE-0002kk-He for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 20:46:32 +0200 Original-Received: from localhost ([::1]:45778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSlnD-00023V-GR for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 14:46:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSlmC-0001Ju-Fm for emacs-devel@gnu.org; Wed, 14 Oct 2020 14:45:28 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:40405 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kSlmA-00051l-3e for emacs-devel@gnu.org; Wed, 14 Oct 2020 14:45:28 -0400 Original-Received: (qmail 11008 invoked by uid 3782); 14 Oct 2020 18:45:23 -0000 Original-Received: from acm.muc.de (p4fe15b87.dip0.t-ipconnect.de [79.225.91.135]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 14 Oct 2020 20:45:23 +0200 Original-Received: (qmail 3182 invoked by uid 1000); 14 Oct 2020 18:45:23 -0000 Content-Disposition: inline In-Reply-To: <838sc8zqjj.fsf@gnu.org> 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-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 14:45:24 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] 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:257673 Archived-At: Hello, Eli. On Wed, Oct 14, 2020 at 20:05:36 +0300, Eli Zaretskii wrote: > > Date: Wed, 14 Oct 2020 16:35:34 +0000 > > Cc: ghe@sdf.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > To me, consistent behavior would be to switch to the mini-window of > > > the selected frame. > > I'm not quite sure what a mini-window is. Does it mean the window within > > which the minibuffer is displayed? As in max-mini-window-height? > The mini-window is the small window at the bottom of the frame which > is used to display the echo area and the minibuffer. Thanks. > > My apologies for being unclear. I was thinking about what happens after > > the Isearch is over. Currently the minibuffer is pulled in if the > > Isearch has used the minibuffer for any reason. With my patch, this > > would never happen after an Isearch. > > What I meant was that with the "always" variation, after an Isearch, an > > open minibuffer would always be pulled over from another frame. > Would you please describe the recipe to try, and then describe how you > would like to change the current behavior in that recipe? I feel that > I don't really understand what you are trying to say (e.g., what does > "minibuffer is pulled in" mean?). Calling the frames F1 and F2: (i) On F1, C-x b ; Leaves a minibuffer open. (ii) Move to F2. (iii) C-s foo RET On the current master, and with my patch, the minibuffer is still on F1. With my "always" variation, the minibuffer would now be on F2 (or, possibly on all frames). ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Starting again from a vanilla state: (iv) On F1, C-x b ; Leaves a minibuffer open. (v) Move to F2. (vi) C-s foo ; Leaves an Isearch active. (vii) C-x 8 RET RET ; Inserts a foreign character into the search string. (viii) RET ; Terminates Isearch. On the current master, the minibuffer has been moved to F2. With my patch, it would still be on F1. With the "always" variation it would be on F2 (or, possibly on all frames). ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; The current master seems to me to be inconsistent, in that whether the minibuffer moves from F1 to F2 depends on whether the Isearch used a (recursive) minibuffer. With my patch, a minibuffer would remain on the frame it was opened on, no matter what. With the "always" variation, a minibuffer would always be on the currently selected frame; selecting a frame, no matter how, would cause any current minibuffer to move to that frame. Thus, I would suggest the following new option (written here as defvar rather than defcustom for ease of writing): ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defvar minibuffer-follows-frame 'hybrid "How a minibuffer moves on selecting a different frame. It takes one of the following values: nil: Minibuffers remain on the frame they were opened on. t: A minibuffers is moved onto the newly selected frame. The symbol `hybrid': A minibuffer is moved on onto the current frame when a recursive minibuffer opened on this frame terminates. `hybrid' corresponds with the standard behavior from Emacs 27 and earlier." ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; I think you are proposing the equivalent of (eq minibuffer-follows-frame t), but I'm not sure. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).