Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Sun, Mar 21, 2021 at 17:43:02 +0200, Eli Zaretskii wrote:
> > Date: Sun, 21 Mar 2021 14:49:56 +0000
> > Cc: jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > It's a "feature" we only allow a single terminal to be in the "input"
> > > state at any given time.

> > Er, OK.  There surely must be good reasons for this.

> The "good reasons" are that we are unable to handle input from two or
> more keyboards: they will mix up into a single garbled stream of input
> events.  That's because there's only one channel through which Emacs
> reads input -- the single event queue we have in keyboard.c.

Thanks, that's very clear.

> > The following description includes things which aren't yet committed.

> > "Move" means to move the minibuffer from frame F1 to frame F2, as for
> > example, C-x 5 o requires when minibuffer-follows-selected-frame is t
> > (the default).  When enable-recursive-minibuffers is t, there can be a
> > "stack" of minibuffers on a frame.  The entire stack gets moved.  The top
> > minibuffer in the stack is at f->minibuffer_window, any lower elements
> > are stored in w->prev_buffers, where w is XWINDOW (f->minibuffer_window).

> > It is also required to move minibuffers when the frame containing them
> > gets deleted.  Otherwise the minibuffers would continue to be active, yet
> > be inaccessible from any frame - this would be undesirable.

> > When the (second) last frame in a --daemon Emacs gets deleted, any
> > minibuffers it contains get moved to the initial frame.  When calling
> > emacsclient opens a new frame, these minibuffers need to be moved onto
> > that new frame (or else be aborted, somehow).

> AFAIU, this just means copying the data that describes the stack of
> the minibuffers, is that right?

Not quite: if there're also minibuffers in the destination frame (with
minibuffer-follows-selected-frame set to nil), the two minibuffer stacks
get combined in the destination.

> If so, what is left on the frame that is the source of that: a single
> empty minibuffer? or the entire original stack? or something else?

What is left on the source frame is a single minibuffer, " *Minibuf-0*",
which functions as the null minibuffer.

> > The problem I'm trying to solve here is to understand what happens when
> > emacsclient opens a frame on a different terminal from where emacs
> > --daemon was started, when there are active minibuffers on the original
> > terminal.  What would be nice would be for these minibuffers to be moved
> > onto the new frame (when minibuffer-follows-selected-frame is t) or left
> > on the other non-initial frame (otherwise).  It appears, from Miha's
> > observation yesterday, that any active minibuffers would get aborted in
> > this case, to prevent the old frame blocking the new one.

> And what's wrong with aborting the active minibuffer in this case?

I don't think there's all that much wrong with aborting it.  It is a
little inconsistent with creating a new emacsclient frame on the same
terminal - here, any existing minibuffers survive.

> isn't that what the user wants?

I honestly don't know.  But as long as the code ends up doing something
consistent and reasonable (and this aborting the minibuffers _is_
reasonable), I don't think it's worth spending too much time on.  Given
how there's just one keyboard input stream, it would be a LOT of work to
make that one input stream per terminal.  We surely don't really need
this.

-- 
Alan Mackenzie (Nuremberg, Germany).