Re: Stop frames stealing eachothers' minibuffers!

[Gregory Heytings]

> > 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.
>
> There are two things we could consider with 
> 'minibuffer-follows-selected-frame' non-nil:
>
> - Optionally, don't move the minibuffer window too eagerly. Moving the 
> prompt to my separate *Info* frame that I just want to consult for the 
> interaction I'm about to perform might look gratuitous.

It does, definitely.  What you describe here is the behavior of Emacs 
21-27, IIUC.

> - Optionally, tie the frame where a minibuffer interaction was initiated 
> to that minibuffer and when the ensuing action is performed, make that 
> frame the selected one.

Isn't this what minibuffer-follows-selected-frame t is supposed to do? 
(Except that the frame is not automatically selected.)

> But I think the main task for the moment is to fix the 
> 'minibuffer-follows-selected-frame' nil behavior.

The minibuffer-follows-selected-frame t behavior is also broken, alas, at 
least it doesn't do what the NEWS item says it should do.

My feeling is also that "minibuffer-follows-selected-frame" is not a good 
generic name for all these behaviors.  Perhaps one should have something 
like "recursive-minibuffer-behavior" with several possible values:

move-to-selected-frame-on-activation
always-on-selected-frame
always-on-selected-frame-and-raise-activation-frame
tie-to-activation-frame

(This is just a draft.  Perhaps these options should in fact be split in 
two separate options.)