Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

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

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

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

> So if we cannot reconcile our preferences, maybe we should have a user
> option to decide which behavior to choose.

Perhaps.  If we can formulate the two (or several) options in a
non-confusing way.  This is a fairly arcane matter.

> > 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 don't think I follow: Isearch doesn't use the minibuffer.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).