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: Sun, 7 Feb 2021 12:55:06 +0000 Message-ID: References: <87wnvkixrv.fsf@miha-pc> 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="8053"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: jakanakaevangeli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Feb 07 13:56:59 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 1l8jcY-0001zH-2Q for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Feb 2021 13:56:58 +0100 Original-Received: from localhost ([::1]:45812 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l8jcX-0005sB-50 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Feb 2021 07:56:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l8jat-00052x-8z for emacs-devel@gnu.org; Sun, 07 Feb 2021 07:55:16 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53041 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1l8jap-0002Ea-IK for emacs-devel@gnu.org; Sun, 07 Feb 2021 07:55:15 -0500 Original-Received: (qmail 13627 invoked by uid 3782); 7 Feb 2021 12:55:07 -0000 Original-Received: from acm.muc.de (p4fe15177.dip0.t-ipconnect.de [79.225.81.119]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Feb 2021 13:55:06 +0100 Original-Received: (qmail 11862 invoked by uid 1000); 7 Feb 2021 12:55:06 -0000 Content-Disposition: inline In-Reply-To: <87wnvkixrv.fsf@miha-pc> X-Submission-Agent: TMDA/1.3.x (Ph3nix) 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=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:264115 Archived-At: Hello again, jakanakaevangeli. On Sun, Feb 07, 2021 at 00:25:56 +0100, jakanakaevangeli wrote: > Thanks for your hard work. Just as a matter of interest, your email host rejected my post yesterday, saying that the interchange had to start with a STARTTLS command. > 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". Yes. That happens even on C-] when there's just a single recursive edit in progress. > > 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: [ .... ] It turns out the tools in place were adequate to fix the problem without too much trouble. The critical thing is in internal_catch to distinguish between minibuffer throws and recursive edit throws, and only throw again for the minibuffer case. Additionally, minibuf_c_loop_level should now be made a static function, but I can do that later. Could I ask you please to try out the following patch, which should be applied on top of yesterday's patch: --- src/eval.c~ 2021-02-06 12:44:35.798096526 +0000 +++ src/eval.c 2021-02-07 12:27:09.927308860 +0000 @@ -1199,9 +1199,10 @@ { if (minibuffer_quit_level == -1) minibuffer_quit_level = this_minibuffer_depth (Qnil); - if (minibuf_level > minibuffer_quit_level - || command_loop_level - > minibuf_c_loop_level (minibuffer_quit_level)) + /* MINIBUFFER_QUIT_LEVEL == 0 -> not in minibuffer. */ + if (minibuffer_quit_level + && minibuf_level > minibuffer_quit_level + && !NILP (Fminibuffer_innermost_command_loop_p (Qnil))) Fthrow (Qexit, Qt); else minibuffer_quit_level = -1; --- src/minibuf.c~ 2021-02-06 15:04:58.878632379 +0000 +++ src/minibuf.c 2021-02-07 12:02:54.913389037 +0000 @@ -437,6 +437,8 @@ if (!minibuf_depth) error ("Not in a minibuffer"); + if (NILP (Fminibuffer_innermost_command_loop_p (Qnil))) + error ("Not in most nested command loop"); if (minibuf_depth < minibuf_level) { array[0] = fmt; -- Alan Mackenzie (Nuremberg, Germany).