Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Oct 15, 2020 at 16:44:42 +0300, Eli Zaretskii wrote:
> > 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
> branch looks 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.

OK, but I disagree.  We seem to have different mental models of the
minibuffer.  For you, the MB, I think, is what demands immediate
attention, therefore should be on the selected frame.  For me, the MB is
an integral part of the frame on which it was opened.

Is there any chance we could implement an option for this (which has been
mentioned already)?

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

Yes, that needs consideration.  An iconified frame could be restored, but
I'm not sure about a deleted frame.  Maybe deleting a frame with an open
MB on it should kill the MB together with the command which is using it.
Or something like that.

> The only sane place to continue interaction is on the selected frame
> ...

I don't think I agree with "only".  We have problems if, say, the frame
is an ediff frame detached from what it's working on.  We have problems
if the frame is too small to hold the MB's prompt.

> .... (and let's leave the use case of separate minibuffer-only frame
> aside, okay?).

Well, we'll need to deal with it at some stage.

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

The problem happens to me when I've forgotten I've still got an open
minibuffer on the other frame.  This happens, for example, when I need to
search a buffer to find out what to type into, say, M-x imenu, and then
get distracted by whatever.

Anyhow, back to practicalities.  I think we agreed last night (talking
about the "hybrid" option) that the current way of doing things isn't
very good.  I think, but I'm not sure, that you're saying the MB, if
open, should always be present on the currently selected frame and
nowhere else.  If I'm wrong here, could you possibly give a precise
description of when you say the MB should be moved to a different frame.

From a C coding point of view, if nothing special is done, the MB remains
on the frame it was opened on.  (My patch was nothing but the removal of
code which moved the MB.)  The code I removed was somewhat tangled.  If
we're going to implement "MB follows selected frame", we may well want to
add a call to minibuf.c from frame.c.  This will need doing with care.

-- 
Alan Mackenzie (Nuremberg, Germany).