Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> 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:
> 
> (i) On F1, C-x b  ; Leaves a minibuffer open.
> (ii) Move to F2.
> (iii) C-s foo RET
> 
> On the current master, and with my patch, the minibuffer is still on F1.
> With my "always" variation, the minibuffer would now be on F2 (or,
> possibly on all frames).
> 
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> 
> 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.

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

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

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