Re: Stop frames stealing eachothers' minibuffers!

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> A: type C-x C-f on frame F1, switch to frame F2
>> B: type C-x C-f on frame F1, switch to frame F2, type M-:
>
>> [1] There is also a severe regression in this case.  Type C-x C-f on frame 
>> F1, switch to frame F2, type M-:.  "Find file" is still visible in the 
>> miniwindow on frame F1; switch to frame F1.
>
>> Experiment 1: Type the name of a file and RET.  You'll get the error 
>> message "End of file during parsing", and MB2 on frame F2 will be left. 
>> MB1 is now unuseable, and impossible to leave, it will stay on F1 whatever 
>> you do.
>
>> Experiment 2: Type C-g.  MB2 on frame F2 will be left, and "Find file" 
>> will stay in MB1 on frame F1.  However you cannot use it anymore, the 
>> keymap of MB1 is now minibuffer-inactive-mode-map.  And like in experiment 
>> 1, you cannot leave it.
>
> The abstract cause of this situation would appear to be using F1's
> minibuffer while a more deeply nested minibuffer is still active.

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.

I expect that this is the core origin of the problem.

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.

[ Another way to attack the problem would be to arrange it so that every
  minibuffer runs in its own thread, so you can exit one without
  affecting the other.  I think it might be an interesting direction,
  but it's probably not trivial.  In any case, cmpletely out of scope
  of the present problem.  ]


        Stefan