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, 7 Jan 2021 17:36:13 +0000 Message-ID: References: <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> 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="22968"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 07 18:48:20 2021 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 1kxZOV-0005sM-Gg for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 18:48:19 +0100 Original-Received: from localhost ([::1]:51884 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxZOU-0005gf-IS for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 12:48:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57172) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxZCx-0001gZ-HM for emacs-devel@gnu.org; Thu, 07 Jan 2021 12:36:24 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:56289 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1kxZCs-00020T-BG for emacs-devel@gnu.org; Thu, 07 Jan 2021 12:36:23 -0500 Original-Received: (qmail 7348 invoked by uid 3782); 7 Jan 2021 17:36:15 -0000 Original-Received: from acm.muc.de (p4fe15aa4.dip0.t-ipconnect.de [79.225.90.164]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 07 Jan 2021 18:36:13 +0100 Original-Received: (qmail 8061 invoked by uid 1000); 7 Jan 2021 17:36:13 -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:262696 Archived-At: Hello again, Martin. On Tue, Jan 05, 2021 at 19:53:23 +0100, martin rudalics wrote: > >> - doesn't get me _always_ into the minibuffer window of the frame > >> switched to (I'm not sure whether it should and under which > >> circumstances - this should be clarified), > > I don't think it should, in general, unless the miniwindow is (still) the > > frame's current window. > OK. Let's stick to this rule. :-) > > I've found out why, in Gregory's scenario, after the "middle" RET to > > visit a file, point was not moving back to the "middle frame": it's > > because select_frame is insufficient of itself to move X-Window's focus, > > which stays in the "old" frame. Any command now causes a "switch-frame" > > event which moves the minibuffers back into the "old" frame, which isn't > > what we want. The solution (a bit ugly) is to call the lisp function > > select-frame-set-input-focus rather than just do_switch_frame near the > > end of read_minibuf. > This is indeed ugly and might harm 'redirect-frame-focus'. Actualy, I don't think it's as ugly as all that. select-frame-set-input-focus is an extremely coherent function; it does one thing and does it well, i.e. switch frames. Maybe it's a pity that it's a Lisp function rather than a C function, but it is as it is. I've been trying to think through the bit about redirect-frame-focus. It's difficult. Are you aware of any particular scenarios where it might go wrong with select-frame-set-input-focus? Or is it more a general concern, possibly from past experience? For example if the source frame has focus redirected to a MB-only frame, and s-f-s-i-focus is called, should that redirected focus be undone? I'm a little confused about the difference between a MB-only frame being the selected frame, and it being the focus frame of a different "normal" frame. > >> How do I edit an outer level minibuffer whilst an inner level buffer is > >> active? > > At the moment, you can't. This isn't good. > I think it is good (enough). Do we want spaghetti minibuffers? I've changed the handling of outer level minibuffers so that they can be freely edited (but not exited, see below). > > What do you think of the > > following solution? > > Instead of setting outer minibuffers' maps temporarily to > > minibuffer-inactive-mode-map, I could amend exit-minibuffer so that > > it would throw an error when there was a more nested active > > minibuffer, but leave the current minibuffers untouched. Also, C-g > > should then abort the current minibuffer's caller, together with > > those of any more nested MBs. > We're right in hell's kitchen here. I've actually implemented the above, on a trial basis. It was actually surprisingly easy. The C-g bit was just 9 extra lines (plus comments) in internal_catch (eval.c), and another small function in minibuf.c. You say "hell's kitchen". Again, is this on general principles, or can you see some specific problems which might crop up? My feeling is that this way of dealing with "not the innermost minibuffer" is simple, and possibly as good as we're going to get. Another possibility, is that rather than a stack of minibuffers, we have a collection of minibuffers, any one of which (which is accessible) can be used and exited at any time. But I can foreseen lots of unforeseen problems happening with this, and I don't want to try to implement it at the moment. > > The change in the current version of the patch (attached) is that, > > as already mentioned, select-frame-set-input-focus is called rather > > than just do_select_frame from near the end of read_minibuf. Also, > > that call has been moved from just after the recursive edit to the > > very end of read_minibuf. Also, move_minibuffer_onto_frame now > > moves the entire stack of minibuffers, not just the current one (it > > is not called when minibuffers-follows-selected-frame is nil). > > How would you feel about committing this patch? It is an improvement > > over the current state, even though not yet finished. > Let's wait for a week at least. I'd really want to hear the comments > from the rest of the bunch. OK. My feeling at the moment is the patch is now finished (apart from some documentation changes). Maybe I should push out another patch, though I'm not doing that right at the moment. > martin -- Alan Mackenzie (Nuremberg, Germany).