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: jakanakaevangeli
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Sun, 07 Feb 2021 00:25:56 +0100

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



reply via email to

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