From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: jakanakaevangeli Newsgroups: gmane.emacs.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Wed, 03 Feb 2021 16:20:50 +0100 Message-ID: <87wnvpxjn1.fsf@miha-pc> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29752"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: acm@muc.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 03 17:31:33 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 1l7L41-0007da-D5 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Feb 2021 17:31:33 +0100 Original-Received: from localhost ([::1]:41114 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l7L40-0005US-51 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Feb 2021 11:31:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36858) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l7Jtx-0003Ns-U3 for emacs-devel@gnu.org; Wed, 03 Feb 2021 10:17:06 -0500 Original-Received: from chiru.no ([142.4.209.132]:37004) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1l7Jtw-00087O-C0 for emacs-devel@gnu.org; Wed, 03 Feb 2021 10:17:05 -0500 Original-Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id 3AEB8128001C; Wed, 3 Feb 2021 15:17:02 +0000 (UTC) In-Reply-To: X/pQEJzrr+ygUTQi@ACM Received-SPF: none client-ip=142.4.209.132; envelope-from=jakanakaevangeli@chiru.no; helo=chiru.no 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_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 03 Feb 2021 11:26:12 -0500 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:263805 Archived-At: I am reporting three technical problems with the current minibuffer quitting behaviour (on commit 20e48b6fd6cade60e468140a66127d326abfb8ff, after your patch was applied): 1) If you enter a (non-minibuffer) M-x recursive-edit inside a minibuffer, abort-minibuffers (bound to C-g) will quit the inner recursive edit but not the minibuffer, which is what the command's doc-string suggests. This is only a minor inconvenience. In fact, this behaviour is consistent with previous Emacs versions. 2) If you - set minibuffer-follows-selected-frame to nil, - open a minibuffer on frame A, - open a new inner minibuffer on frame B, - enter a M-x recursive-edit in this minibuffer, - select frame A's outer minibuffer, press C-g and answer yes, abort-minibuffers will fail to quit the outer minibuffer, it will not be visible in the mini-window, but you can check by evaluating (minibuffer-depth). 3) This one is a bit opinionated: internal_catch now has undocumented special handling for Qexit. I have come up with an idea to fix all of the above problems: - revert the special handling of Qexit in internal_catch - in read_minibuf, wrap the call to recursive_edit_1 with a catch for symbol exit-read-minibuffer - throwing to this symbol with nil or t shall have the same effect as throwing nil or t to 'exit - throwing to this symbol with a natural number N shall re-throw to this same symbol with N-1 (or quit if N<=1), effectively quitting out of N minibuffers - make exit-minibuffer throw to 'exit-read-minibuffer - make quit-minibuffers throw to 'exit-read-minibuffer with minibuf_level - this_minibuf_depth () + 1 Please let me know if you find this idea worthy of implementing and if you want me to try implementing it and posting a patch.