Re: Stop frames stealing eachothers' minibuffers!

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

>> With Emacs 28 (-Q), the active minibuffer is moved from frame F1 to 
>> frame F2 at step (iii), _before_ you answer the C-x 8 RET. That is, the 
>> active minibuffer is moved from frame F1 to frame F2 whenever you 
>> switch from frame F1 to frame F2.
>>
>> With Emacs 21-27, this happens only at step (iv), _after_ you hit C-x 8 
>> RET.  That is, the active minibuffer is moved from frame F1 to frame F2 
>> only when you activate a new minibuffer on frame F2.
>
> I understand you now.  With Emacs 27 the minibuffer window moves lazily 
> - that is, only when it's needed on some other frame - with Emacs 28 it 
> moves eagerly.  That doesn't look like a change for the better.  Alan, 
> couldn't we try to do that by giving 'minibuffer-follows-selected-frame' 
> a third value like 'on-demand and move only when the user really wants 
> to interact with the minibuffer on another frame?
>

Yes, AFAIU doing this would amount to make it possible to restore the 
Emacs 21-27 behavior, which would be a good thing.

BTW, this (to have three possible behaviors) is what I suggested as early 
as Oct 14.  This suggestion was totally ignored:

1. the Emacs 21-27 behavior, with which all recursive minibuffers are 
moved from one frame to another when one or more minibuffers are active in 
one frame, and a new recursive activation happens in another frame: that's 
what we lost

2. move all recursive minibuffers from one frame to the other when 
switching to another frame: that's what we now have with 
minibuffer-follows-selected-frame set to t, except that it doesn't work as 
it should (the result of the commands do not take place in the frame in 
which they were initiated)

3. tie each one of the recursive minibuffers to the frame in which it was 
activated: that's what we now have with minibuffer-follows-selected-frame 
set to nil, except that it doesn't work as it should (interacting with the 
minibuffers that are not the most recently entered one break things badly)

My feeling (I did not look at the code) is that too many things were 
changed at once.  Perhaps this should be done / have been done in two 
steps, first implement the additional behavior 2, then behavior 3.