Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 19:49:04 +0000
> Cc: ghe@sdf.org, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > 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.

We are talking past each other.  This behavior of the current emacs-27
branchlooks correct to me:

  On F1, C-x b
  Move to F2
  C-s foo ; Isearch prompt appears in F2's echo area
  C-x 8 RET <some character> RET; editing is in F2's minibuffer
  RET ; terminates Isearch and leaves the active minibuffer on F2

This behavior is wrong:

  On F1, C-x b
  Move to F2
  C-s foo ; Isearch prompt appears in F2's echo area
  RET ; terminates Isearch and leaves the active minibuffer on F1

The latter is correct, except for the last step: the active minibuffer
should have switched to F2, which is now the selected frame.

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

There's no guarantee of that.  Moreover, a non-selected frame could
have been iconified or even deleted.  The only sane place to continue
interaction is on the selected frame (and let's leave the use case of
separate minibuffer-only frame aside, okay?).

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

Not clear why: you switched to another frame, so continue using that.
If you want to continue using the original frame, switch back there.