emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stop frames stealing eachothers' minibuffers!


From: Alan Mackenzie
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Sun, 7 Feb 2021 12:55:06 +0000

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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]