Re: Stop frames stealing eachothers' minibuffers!

[jakanakaevangeli]

I am reporting three technical problems with the current minibuffer
quitting behaviour (on commit 20e48b6fd6cade60e468140a66127d326abfb8ff,
after your patch was applied):

1) If you enter a (non-minibuffer) M-x recursive-edit inside a
   minibuffer, abort-minibuffers (bound to C-g) will quit the inner
   recursive edit but not the minibuffer, which is what the command's
   doc-string suggests. This is only a minor inconvenience. In fact,
   this behaviour is consistent with previous Emacs versions.

2) If you
   - set minibuffer-follows-selected-frame to nil,
   - open a minibuffer on frame A,
   - open a new inner minibuffer on frame B,
   - enter a M-x recursive-edit in this minibuffer,
   - select frame A's outer minibuffer, press C-g and answer yes,
   abort-minibuffers will fail to quit the outer minibuffer, it will not
   be visible in the mini-window, but you can check by evaluating
   (minibuffer-depth).

3) This one is a bit opinionated: internal_catch now has undocumented
   special handling for Qexit.

I have come up with an idea to fix all of the above problems:
- revert the special handling of Qexit in internal_catch
- in read_minibuf, wrap the call to recursive_edit_1 with a catch for
  symbol exit-read-minibuffer
- throwing to this symbol with nil or t shall have the same effect as
  throwing nil or t to 'exit
- throwing to this symbol with a natural number N shall re-throw to this
  same symbol with N-1 (or quit if N<=1), effectively quitting out of N
  minibuffers
- make exit-minibuffer throw to 'exit-read-minibuffer
- make quit-minibuffers throw to 'exit-read-minibuffer with
  minibuf_level - this_minibuf_depth () + 1

Please let me know if you find this idea worthy of implementing and if
you want me to try implementing it and posting a patch.