Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Gregory.

On Wed, Nov 25, 2020 at 21:31:13 +0000, Gregory Heytings wrote:


> > The behaviour in Emacs 27 is chaotic.  Sometimes a minibuffer moves with 
> > a frame switch, sometimes it doesn't.

> I wouldn't write it is "chaotic".  The behavior you consider "chaotic" is 
> well-defined, and has been there since Emacs 21 at least: the minibuffer 
> moves from frame F1 to frame F2 if and only if the minibuffer is active on 
> frame F1 and a recursive minibuffer is entered on frame F2.

I'm not sure what you mean by "is" in that sentence.

> There are other possible behaviors of course, but IMO the current one
> is a reasonable one.

If a recursive minibuffer operation has been carried out, then the
minibuffer moves, if it hasn't it doesn't.  That means Emacs has some
invisible internal state, something which doesn't seem desirable.

> > Also, how often do people actually select minibuffer-only frames? Unless 
> > I'm missing something, it seems a rather strange thing to want to do.

> There are at least two Emacs users on this list who use minibuffer-only 
> frames: Stefan and Drew.

Sorry, I don't think I was clear.  By "select .... frames" I meant the
operation of making the minibuffer frame the current frame, not the
chosing of an Emacs setup which includes minibuffer-only frames.  Such a
minibuffer-only frame comes into operation whenever a minibuffer action
is invoked in another frame, but actually selecting it independently of
such a minibuffer action?

> I'm also curious why they do this, and would be interested if they
> could explain what the benefit of doing this is.

It's also not a setup I would want to use.  By preference, I use the
Linux tty and only ever have one frame on the screen at a time.  But I
can imagine people wanting their interactive minibuffer always to be in
the same place on a GUI screen.  Or something like that.  Maybe Stefan or
Drew will answer this.

-- 
Alan Mackenzie (Nuremberg, Germany).