[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
- Re: Stop frames stealing eachothers' minibuffers!, jakanakaevangeli, 2021/02/03
- Re: Stop frames stealing eachothers' minibuffers!,
jakanakaevangeli <=
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/02/07
- Re: Stop frames stealing eachothers' minibuffers!, jakanakaevangeli, 2021/02/07
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/02/07
- RE: [External] : Re: Stop frames stealing eachothers' minibuffers!, Drew Adams, 2021/02/07
- Re: Stop frames stealing eachothers' minibuffers!, jakanakaevangeli, 2021/02/08
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/02/11
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2021/02/11
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2021/02/12