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:02:40 +0000 Message-ID: <20201014160240.GA7651@ACM> References: <20201013190255.GA8896@ACM> <838sca0w7k.fsf@gnu.org> <20201013195103.GB8896@ACM> <20201013204408.GC8896@ACM> <831ri027vz.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="39568"; 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:12: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 1kSjOP-000ADt-LA for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 18:12:45 +0200 Original-Received: from localhost ([::1]:33022 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSjOO-0004Ey-Kp for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 12:12:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSjEm-00078m-G7 for emacs-devel@gnu.org; Wed, 14 Oct 2020 12:02:49 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:33684 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kSjEj-0001Tj-3F for emacs-devel@gnu.org; Wed, 14 Oct 2020 12:02:48 -0400 Original-Received: (qmail 22599 invoked by uid 3782); 14 Oct 2020 16:02:41 -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:02:40 +0200 Original-Received: (qmail 7700 invoked by uid 1000); 14 Oct 2020 16:02:40 -0000 Content-Disposition: inline In-Reply-To: <831ri027vz.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:257652 Archived-At: Hello, Eli. On Wed, Oct 14, 2020 at 17:34:56 +0300, Eli Zaretskii wrote: > > Date: Tue, 13 Oct 2020 20:44:08 +0000 > > Cc: Eli Zaretskii , emacs-devel@gnu.org > > From: Alan Mackenzie > > > > If the command using the minibuffer is given on frame F1, and the > > > > selected frame becomes F2, the minibuffer sometimes moves, sometimes > > > > doesn't, depending on what the user does. For example, C-s in F2 > > > > doesn't usually move the minibuffer, but it will if you use C-x 8 > > > > RET. This is inconsistent. > > > You are confusing two things here: the minibuffer (for interactive use) > > > and the echo area (for messages). C-s uses the echo area, C-x C-f and > > > C-x 8 RET use the minibuffer. > > 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. 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 favour the "never" option of course, but going with "always", the logical endpoint is surely that an open minibuffer will always be displayed on the currently selected frame. It is only slightly more extreme to display that minibuffer on _every_ frame. That would be consistent, but I don't think I would like it very much. -- Alan Mackenzie (Nuremberg, Germany).