Re: Stop frames stealing eachothers' minibuffers!

[martin rudalics <rudalics@gmx.at>]

 > I wouldn't write it is "chaotic".  The behavior you consider "chaotic"
 > is well-defined, and has been there since Emacs 21 at least: the
 > minibuffer moves from frame F1 to frame F2 if and only if the
 > minibuffer is active on frame F1 and a recursive minibuffer is entered
 > on frame F2.  There are other possible behaviors of course, but IMO
 > the current one is a reasonable one.

The basic behavioral change I see is with 'enable-recursive-minibuffers'
non-nil and two frames: When I type C-h f setq in the first frame and
C-h f cons in the second frame, hit RET, reselect the minibuffer window
and hit RET again, with Emacs 27 a help window pops up in the first
frame while Emacs 28 reuses the help window of the second frame.  In
both cases the second RET goes to the second frame and both behaviors
seem reasonable to me.

If, with Emacs 28, I set 'minibuffer-follows-selected-frame' to non-nil,
the behavior does not entirely match that of Emacs 27 because the second
RET must be typed in the first frame.  So if some application relies on
the exact replication of the behavior of Emacs 27, we have a regression.

martin