Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier]

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