Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> 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 frame to be in the "input"
state at any given time.

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