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 16:35:34 +0000 Message-ID: <20201014163534.GB7651@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> 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="34105"; 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 18:37:21 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 1kSjmC-0008ll-SI for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 18:37:20 +0200 Original-Received: from localhost ([::1]:34790 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSjmB-0004gF-QC for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 12:37:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSjka-0003RJ-Bz for emacs-devel@gnu.org; Wed, 14 Oct 2020 12:35:44 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:35040 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kSjkX-0005Y3-FP for emacs-devel@gnu.org; Wed, 14 Oct 2020 12:35:39 -0400 Original-Received: (qmail 42381 invoked by uid 3782); 14 Oct 2020 16:35:34 -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 18:35:34 +0200 Original-Received: (qmail 7891 invoked by uid 1000); 14 Oct 2020 16:35:34 -0000 Content-Disposition: inline In-Reply-To: <83d01kzswk.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 12:02:41 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=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:257655 Archived-At: Hello, Eli. On Wed, Oct 14, 2020 at 19:14:35 +0300, Eli Zaretskii wrote: > > Date: Wed, 14 Oct 2020 16:02:40 +0000 > > Cc: ghe@sdf.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > Sorry, I meant the use of C-x 8 RET from within isearch. In that sense, > > > > usually C-s will not suck in an active minibuffer, but it will if you > > > > have to type foreign characters into your search string. This is > > > > inconsistent. > > > So maybe we should fix this inconsistency, not disable the switch to > > > the selected frame where that is useful and expected? > > Well, my patch _does_ fix the inconsistency, by tying each minibuffer > > absolutely to the frame it acts on. It never occurred to me, until a > > few days ago, that anybody might find that strategy strange or awkward. > 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? > So if we cannot reconcile our preferences, maybe we should have a user > option to decide which behavior to choose. Perhaps. If we can formulate the two (or several) options in a non-confusing way. This is a fairly arcane matter. > > Otherwise, to fix this inconsistency in Isearch (when there's a > > minibuffer open in another frame), we must either always pull the > > minibuffer into the Isearch frame, or never. > I don't think I follow: Isearch doesn't use the minibuffer. 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. -- Alan Mackenzie (Nuremberg, Germany).