Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Martin.

On Fri, Nov 27, 2020 at 11:36:47 +0100, martin rudalics wrote:
>  >> 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.

> Right.  I meant "to nil" here.

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

> Having a customizable variable like 'minibuffer-follows-selected-frame'
> whose purpose is to get back the old behavior, should also provide that
> old behavior as faithfully as possible IMHO.

That is not the purpose of the variable.  The purpose is to be able to
chose between mental models of a minibuffer in a frame.  Eli's mental
model is that the MB represents the action which should be performed
next.  Mine is that a MB is part of the frame it is opened in.  So Eli
gets to leave m-f-s-f at t, I get to set it to nil.

The old behaviour was chaotic and unsystematic, and Eli and I agreed
this earlier on in the thread.  The recent changes were an attempt to
bring the behaviour back, at least partially, to something systematic.
The new variable m-f-s-f should enable a user to set the behaviour she
wants.  Maybe there's something missing (aside from bugs which still
need fixing).

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).