Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>]

>
> 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?  IOW, that exit-minibuffer 
was so far only meant to be used for the most recent minibuffer?

BTW, I played a bit with this, and it seems that recursive minibuffers on 
more than two frames do not work correctly, since Emacs 21 at least. 
Here is a recipe you can try with Emacs 21-28:

emacs -Q
M-: (setq enable-recursive-minibuffers t) RET
C-x C-f ; create MB1 on frame F1
C-x 5 2
C-x C-f ; move MB1 to frame F2 and create MB2
C-x 5 2
C-x C-f .emacs RET ; create MB3 on frame F3, open file in frame F3
C-x o .emacs RET ; activate MB2 on frame F3, open file in frame F2

At that point MB2 is moved to frame F2, and is now unuseable (in 
minibuffer-inactive-mode).  You can either abort-recursive-edit (which 
works), or exit-recursive-edit (which, strangely, opens Dired on frame 
F1).

You can add more frames to the recipe, only the two last ones will work as 
expected.

What should have happened is that, at the end of the recipe, MB2 should 
have been exited and MB1 should be activated on frame F3, so that C-x o 
.emacs RET would open the file in frame F1.

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

IMO the old behavior (with the bug above fixed) and a new behavior 
"minibuffer-follows-selected-frame" which would give a similar experience 
to that of using a minibuffer-only window, should be enough.  What is the 
added value of tying minibuffers to the frames in which they were created, 
compared to the price of implementing that feature?