Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Oct 14, 2020 at 20:05:36 +0300, Eli Zaretskii wrote:
> > Date: Wed, 14 Oct 2020 16:35:34 +0000
> > Cc: ghe@sdf.org, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > To me, consistent behavior would be to switch to the mini-window of
> > > the selected frame.

> > I'm not quite sure what a mini-window is.  Does it mean the window within
> > which the minibuffer is displayed?  As in max-mini-window-height?

> The mini-window is the small window at the bottom of the frame which
> is used to display the echo area and the minibuffer.

Thanks.

> > My apologies for being unclear.  I was thinking about what happens after
> > the Isearch is over.  Currently the minibuffer is pulled in if the
> > Isearch has used the minibuffer for any reason.  With my patch, this
> > would never happen after an Isearch.

> > What I meant was that with the "always" variation, after an Isearch, an
> > open minibuffer would always be pulled over from another frame.

> Would you please describe the recipe to try, and then describe how you
> would like to change the current behavior in that recipe?  I feel that
> I don't really understand what you are trying to say (e.g., what does
> "minibuffer is pulled in" mean?).

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

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

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.

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

With the "always" variation, a minibuffer would always be on the
currently selected frame; selecting a frame, no matter how, would cause
any current minibuffer to move to that frame.

Thus, I would suggest the following new option (written here as defvar
rather than defcustom for ease of writing):

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(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 you are proposing the equivalent of (eq minibuffer-follows-frame
t), but I'm not sure.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).