[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stop frames stealing eachothers' minibuffers!
From: |
Stefan Monnier |
Subject: |
Re: Stop frames stealing eachothers' minibuffers! |
Date: |
Sat, 28 Nov 2020 16:10:31 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
>> More specifically, it's the act of leaving MB1 when there's a deeper MB2
>> active: the code for leaving a minibuffer (e.g. `exit-minibuffer` or
>> `abort-recursive-edit`) doesn't actually pay attention to which minibuffer
>> is currently being used: while it's run from MB1 it actually exits MB2.
>> I'm not completely sure why we end up with a broken state, but I guess
>> it's because some of the code that "deactivates" the minibuffer upon exit
>> in run in the minibuffer that the users thought they were about to exit
>> rather than in the one that is actually exited.
> Isn't the main reason for this that it has never been possible to interact
> with a MBn when a MBm, with m > n, was active?
Well, it's at best an indirect cause of the bug, but yes, it's the
reason why this bug wasn't visible until now.
>> One way to address it might be to make every minibuffer use a different
>> exit tag (instead of the constant `exit` symbol), so that the `throw` will
>> not be caught by some unrelated `catch`. Additionally, we may want to
>> tweak `exit-minibuffer` and `abort-recursive-edit` so that the user is
>> warned/prompted before "silently" canceling that other
>> (deeper) minibuffer.
> Is such an added complexity really worth the price?
I don't see much complexity here. The main issue is not complexity but
the fact that it's a change, so there can be backward compatibility
issues (most likely the catcher will have catch both the old `exit` tag
as well as the new tag, in case some old code throws the `exit` tag
rather than going through `exit-minibuffer`).
Stefan
- Re: Stop frames stealing eachothers' minibuffers!, (continued)
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!,
Stefan Monnier <=
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/28
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/29
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, martin rudalics, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Alan Mackenzie, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Eli Zaretskii, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Gregory Heytings, 2020/11/27
- Re: Stop frames stealing eachothers' minibuffers!, Stefan Monnier, 2020/11/27