Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

[ "frame" replaced by "terminal" where appropriate ]

Hello, Eli.

On Sun, Mar 21, 2021 at 12:38:34 +0200, Eli Zaretskii wrote:
> > Date: Sun, 21 Mar 2021 10:30:39 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org

> > > ;; We're inside a minibuffer already, so if the emacs-client is trying
> > > ;; to open a frame on a new display, we might end up with an unusable
> > > ;; frame because input from that display will be blocked (until exiting
> > > ;; the minibuffer).  Better exit this minibuffer right away.

> > That looks like a bug which ought to be fixed, but I've no idea where to
> > start looking for the problem.

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

> > > `emacsclient ~/foo' causes a throw to top-level in most cases before
> > > spawning a new frame to avoid some trouble, but I'm not sure if this
> > > trouble applies for our case.

> > When starting emacsclient, I've seen minibuffers being preserved, but I
> > think I've also seen them being aborted.  By trouble, I think you mean
> > that described in the comment above.

> I confess that I don't have a clear idea of what is the problem you
> are trying to solve in the context of this discussion.  Why do you
> want to "move" the minibuffer when emacsclient starts a new frame (or
> is it when it closes a frame?), and what does "move" mean in this
> context?

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

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.

It may well be that further work in this area isn't worthwhile - just how
often is somebody going to create a frame in a different terminal whilst
a minibuffer is active, anyway?

-- 
Alan Mackenzie (Nuremberg, Germany).