Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Wed, Oct 14, 2020 at 17:34:56 +0300, Eli Zaretskii wrote:
> > Date: Tue, 13 Oct 2020 20:44:08 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > If the command using the minibuffer is given on frame F1, and the
> > > > selected frame becomes F2, the minibuffer sometimes moves, sometimes
> > > > doesn't, depending on what the user does. For example, C-s in F2
> > > > doesn't usually move the minibuffer, but it will if you use C-x 8
> > > > RET.  This is inconsistent.

> > > You are confusing two things here: the minibuffer (for interactive use)
> > > and the echo area (for messages).  C-s uses the echo area, C-x C-f and
> > > C-x 8 RET use the minibuffer.

> > Sorry, I meant the use of C-x 8 RET from within isearch.  In that sense,
> > usually C-s will not suck in an active minibuffer, but it will if you
> > have to type foreign characters into your search string.  This is
> > inconsistent.

> So maybe we should fix this inconsistency, not disable the switch to
> the selected frame where that is useful and expected?

Well, my patch _does_ fix the inconsistency, by tying each minibuffer
absolutely to the frame it acts on.  It never occurred to me, until a
few days ago, that anybody might find that strategy strange or awkward.

Otherwise, to fix this inconsistency in Isearch (when there's a
minibuffer open in another frame), we must either always pull the
minibuffer into the Isearch frame, or never.

I favour the "never" option of course, but going with "always", the
logical endpoint is surely that an open minibuffer will always be
displayed on the currently selected frame.  It is only slightly more
extreme to display that minibuffer on _every_ frame.

That would be consistent, but I don't think I would like it very much.

-- 
Alan Mackenzie (Nuremberg, Germany).