Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Miha.

On Sat, Mar 20, 2021 at 13:49:19 +0100, Miha Rihtaršič wrote:
> Alan Mackenzie <acm@muc.de> writes:

> >> No, I'm saying that the initial frame is never deleted.  At least
> >> that's my recollection.

> > So, when a new frame is created (possibly with emacsclient), and there
> > are now exactly two frames, we want to copy any minibuffers from the
> > other frame to the new one when that other frame is the initial frame.

> Just giving a heads up that trouble may arise when moving a minibuffer
> from one terminal to another (from tty to X for example).
> This is judging from the following comment that I stumbled upon when
> reading function `server-goto-toplevel':

Thanks.

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

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

On a slightly different note, do you see any reason not to commit the
latest state of src/minibuf.c etc., as amended by my patch from
Wednesday?

-- 
Alan Mackenzie (Nuremberg, Germany).