Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Thu, Nov 26, 2020 at 16:44:11 +0100, martin rudalics wrote:
>  > 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,

Do you mean "to nil", here?  That variable is non-nil by default.

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

Well the new behaviour is explicitly not wholly compatible with the old.
I'm not sure that counts as a regression.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).