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: Sun, 07 Feb 2021 00:25:56 +0100 Message-ID: <87wnvkixrv.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="37414"; 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 Sun Feb 07 03:01:51 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 1l8ZOY-0009dk-5G for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Feb 2021 03:01:50 +0100 Original-Received: from localhost ([::1]:44958 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8ZOX-0006WC-19 for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Feb 2021 21:01:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8Wu1-0000j3-1U for emacs-devel@gnu.org; Sat, 06 Feb 2021 18:22:09 -0500 Original-Received: from chiru.no ([142.4.209.132]:46692) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1l8Wtz-00011j-ET for emacs-devel@gnu.org; Sat, 06 Feb 2021 18:22:08 -0500 Original-Received: from localhost (BSN-77-156-43.static.siol.net [193.77.156.43]) by chiru.no (Postfix) with ESMTPSA id 685F4128001B; Sat, 6 Feb 2021 23:22:05 +0000 (UTC) In-Reply-To: YB67TatiqQOVkt67@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: Sat, 06 Feb 2021 20:58:05 -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:264095 Archived-At: Thanks for your hard work. Your patch fixes the mentioned problems, save for the following regression, which isn't related to minibuffers: upon entering two or more M-x recursive-edit, pressing C-] (abort-recursive-edit) will take you to top-level rather than quit just one recursive edit and produce an error "No catch for tag: exit, t". > The handling you're proposing for exit-read-minibuffer is no less > complicated than what's already there for exit. Actually with function minibuf_c_loop_level, introduced in the patch, you could probably do something similar to my proposed idea by adjusting the catch for Qexit (in command_loop in src/keyboard.c) rather than introducing a new catch for a new Qexit_read_minibuffer. If you have the time and energy, you can read more about this below, where I brainstorm two more ideas. The way I see it, there is, in essence, one problem: we want to quit out of multiple recursive-edit levels. And for this, there are three solutions: 1) internal_catch shall detect if we are in a non-inner minibuffer and re-throw Qexit until necessary. This is the current solution. Pros: - The simplest solution and easiest to maintain Cons: - internal_catch special cases Qexit and is dependent on Fcurrent_buffer (Note that my experience in lisp programming is limited and my gut feeling that this "isn't clean" may be completely misplaced.) 2) command_loop (in src/keyboard.c) shall detect if we are in a non-inner minibuffer and re-throw Qexit until necessary. So basically, move the code from internal_catch to command_loop or recursive_edit_1. Cons: - A bit harder to implement and maintain 3) The catcher for Qexit in command_loop shall be generalized to accept an integer value N, which would mean to re-throw to Qexit with N-1 (or quit if N<=1) and quit-minibuffers shall be adjusted to calculate how many minibuffers to quit with the help of your new minibuf_c_loop_level function. Cons: - The most complicated solution - The new (throw 'exit N) API will have to be documented and maintained - Will probably not be all that useful for users - In could even cause a lot more problems that its worth - Hard to deprecate (perhaps its use could be discouraged or the API considered not supported and only to be used by internal Emacs commands like quit-minibuffers) Pros: - does not rely on static variables - isolates multi-level quitting only to a single command (quit-minibuffers) - Users might get a new possibly useful API for quitting multiple levels