Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

On November 10, 2020 10:08:46 AM GMT+02:00, Andrii Kolomoiets 
<andreyk.mad@gmail.com> wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andrii Kolomoiets <andreyk.mad@gmail.com>
> >> Date: Mon, 09 Nov 2020 22:34:31 +0200
> >> Cc: emacs-devel@gnu.org
> >> 
> >> Alan, is it possible to make 'minibuffer-follows-selected-frame'
> nil by
> >> default?
> >
> > If this is because the other value produces bugs, IMO we should fix
> > those bugs rather than make them less frequent (and thus harder to
> > detect) by flipping the default value.
> 
> It is not producing bugs for me, but changes behavior.
> 
> E.g. in emacs -Q:
> 
> 1. Evaluate
>   (select-frame-set-input-focus
>    (make-frame '((minibuffer . only)
>                  (left . 1.0))))
> 2. M-x
> 3. C-x 5 o
> 
> Before minibuffer-follows-selected-frame, the prompt stays in the
> minibuffer-only frame.
> On recent master, the prompt is moved to other frame leaving
> minibuffer-only frame empty.  I can't report this as a bug.  Just
> wondering why minibuffer-follows-selected-frame is set to t by
> default,
> potentially changing someone's expected behavior.

The defaults are selected for the common usage patterns.  It is not clear to me 
that the test case you presented is common.  But if it is, perhaps we do need 
to consider changing the default.

Does anyone else think this is common usage, to have a minibuffer-only frame 
while other frames also have minibuffers?

Alternatively, perhaps minibuffers activated in minibuffer-only frames should 
behave specially in this regard?