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: Thu, 15 Oct 2020 18:01:43 +0000 Message-ID: <20201015180143.GA10229@ACM> References: <20201013204408.GC8896@ACM> <831ri027vz.fsf@gnu.org> <20201014160240.GA7651@ACM> <83d01kzswk.fsf@gnu.org> <20201014163534.GB7651@ACM> <838sc8zqjj.fsf@gnu.org> <20201014184523.GC7651@ACM> <83y2k8y6qs.fsf@gnu.org> <20201014194904.GD7651@ACM> <83sgafy56d.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="4561"; 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 Thu Oct 15 20:03:19 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 1kT7aw-000133-Tq for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 20:03:18 +0200 Original-Received: from localhost ([::1]:50224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT7av-0006Wf-UO for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 14:03:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60598) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kT7ZV-0005uR-RN for emacs-devel@gnu.org; Thu, 15 Oct 2020 14:01:49 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:53520 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kT7ZS-0001wK-I7 for emacs-devel@gnu.org; Thu, 15 Oct 2020 14:01:49 -0400 Original-Received: (qmail 98836 invoked by uid 3782); 15 Oct 2020 18:01:43 -0000 Original-Received: from acm.muc.de (p4fe15986.dip0.t-ipconnect.de [79.225.89.134]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Thu, 15 Oct 2020 20:01:43 +0200 Original-Received: (qmail 12429 invoked by uid 1000); 15 Oct 2020 18:01:43 -0000 Content-Disposition: inline In-Reply-To: <83sgafy56d.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/15 14:01:44 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:257753 Archived-At: Hello, Eli. On Thu, Oct 15, 2020 at 16:44:42 +0300, Eli Zaretskii wrote: > > Date: Wed, 14 Oct 2020 19:49:04 +0000 > > Cc: ghe@sdf.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > 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). > > > You should try this with the emacs-27 branch, because Gregory's patch > > > installed there (and will be soon merged to master) changes the > > > behavior quite a bit. > > I've just tried it. The behaviour is indeed that which I noted above - > > the minibuffer moves to F2 if and only if a minibuffer has been used in > > Isearch. > > > > 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. > > > AFAICT, this no longer happens. > > Oh, but it does. > We are talking past each other. This behavior of the current emacs-27 > branch looks correct to me: > On F1, C-x b > Move to F2 > C-s foo ; Isearch prompt appears in F2's echo area > C-x 8 RET RET; editing is in F2's minibuffer > RET ; terminates Isearch and leaves the active minibuffer on F2 > This behavior is wrong: > On F1, C-x b > Move to F2 > C-s foo ; Isearch prompt appears in F2's echo area > RET ; terminates Isearch and leaves the active minibuffer on F1 > The latter is correct, except for the last step: the active minibuffer > should have switched to F2, which is now the selected frame. OK, but I disagree. We seem to have different mental models of the minibuffer. For you, the MB, I think, is what demands immediate attention, therefore should be on the selected frame. For me, the MB is an integral part of the frame on which it was opened. Is there any chance we could implement an option for this (which has been mentioned already)? > > > > With my patch, a minibuffer would remain on the frame it was > > > > opened on, no matter what. > > > That's a separate issue, I believe. I'm not sure I like the > > > behavior you suggest. If the user switched to a different frame, > > > why should the minibuffer prompt stay on the non-selected frame? > > Because the action which the minibuffer will invoke usually takes place > > in that now non-selected frame. > There's no guarantee of that. Moreover, a non-selected frame could > have been iconified or even deleted. Yes, that needs consideration. An iconified frame could be restored, but I'm not sure about a deleted frame. Maybe deleting a frame with an open MB on it should kill the MB together with the command which is using it. Or something like that. > The only sane place to continue interaction is on the selected frame > ... I don't think I agree with "only". We have problems if, say, the frame is an ediff frame detached from what it's working on. We have problems if the frame is too small to hold the MB's prompt. > .... (and let's leave the use case of separate minibuffer-only frame > aside, okay?). Well, we'll need to deal with it at some stage. > > I feel a bit of a jolt when I hit RET in F2, but the effect (of > > switch-to-buffer) takes place in F1. This applies to C-x C-f, C-x > > C-w, C-x b, M-x imenu, ..... > Not clear why: you switched to another frame, so continue using that. > If you want to continue using the original frame, switch back there. The problem happens to me when I've forgotten I've still got an open minibuffer on the other frame. This happens, for example, when I need to search a buffer to find out what to type into, say, M-x imenu, and then get distracted by whatever. Anyhow, back to practicalities. I think we agreed last night (talking about the "hybrid" option) that the current way of doing things isn't very good. I think, but I'm not sure, that you're saying the MB, if open, should always be present on the currently selected frame and nowhere else. If I'm wrong here, could you possibly give a precise description of when you say the MB should be moved to a different frame. >From a C coding point of view, if nothing special is done, the MB remains on the frame it was opened on. (My patch was nothing but the removal of code which moved the MB.) The code I removed was somewhat tangled. If we're going to implement "MB follows selected frame", we may well want to add a call to minibuf.c from frame.c. This will need doing with care. -- Alan Mackenzie (Nuremberg, Germany).