Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 21:58:35 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 18:45:23 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Calling the frames F1 and F2:

[ .... ]

> > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> > Starting again from a vanilla state:
> > (iv) On F1, C-x b ; Leaves a minibuffer open.
> > (v) Move to F2.
> > (vi) C-s foo ; Leaves an Isearch active.
> > (vii) C-x 8 RET <Some character> RET ; Inserts a foreign character into
> > the search string.
> > (viii) RET ; Terminates Isearch.

> > On the current master, the minibuffer has been moved to F2.  With my
> > patch, it would still be on F1.  With the "always" variation it would be
> > on F2 (or, possibly on all frames).

> You should try this with the emacs-27 branch, because Gregory's patch
> installed there (and will be soon merged to master) changes the
> behavior quite a bit.

I've just tried it.  The behaviour is indeed that which I noted above -
the minibuffer moves to F2 if and only if a minibuffer has been used in
Isearch.

> > The current master seems to me to be inconsistent, in that whether the
> > minibuffer moves from F1 to F2 depends on whether the Isearch used a
> > (recursive) minibuffer.

> AFAICT, this no longer happens.

Oh, but it does.

> > With my patch, a minibuffer would remain on the frame it was opened on,
> > no matter what.

> That's a separate issue, I believe.  I'm not sure I like the behavior
> you suggest.  If the user switched to a different frame, why should
> the minibuffer prompt stay on the non-selected frame?

Because the action which the minibuffer will invoke usually takes place
in that now non-selected frame.  I feel a bit of a jolt when I hit RET in
F2, but the effect (of switch-to-buffer) takes place in F1.  This applies
to C-x C-f, C-x C-w, C-x b, M-x imenu, .....

> > (defvar minibuffer-follows-frame 'hybrid
> >   "How a minibuffer moves on selecting a different frame.
> > It takes one of the following values:
> > nil: Minibuffers remain on the frame they were opened on.
> > t: A minibuffers is moved onto the newly selected frame.
> > The symbol `hybrid': A minibuffer is moved on onto the current frame when
> > a recursive minibuffer opened on this frame terminates.

> > `hybrid' corresponds with the standard behavior from Emacs 27 and earlier."

> I think 'hybrid' is no longer needed (and makes little sense as useful
> behavior to me).

I agree, but for backward compatibility....  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).