Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii <eliz@gnu.org>]

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

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

> 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?
isn't that what the user wants?