Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Fri, 19 Mar 2021 15:35:13 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > , the new frame comes up _with_ the minibuffer visible.  I don't
> > > understand how the mini window survived with its contents, and it
> > > worries me.
> 
> > Why does it worry you?  You've asked Emacs to create a frame, and a
> > frame by default has a mini-window.  Right?
> 
> I understand it a lot better now.  The new mini-window gets the
> minibuffers only because I had minibuffer-follows-selected-frame set to
> t.  With either of the other values, the minibuffers remain on the old
> inaccessible frame.  This is not good.

Can't you move them from those inaccessible frames to this one?

> > > Could it be that the last frame isn't actually deleted from the Emacs
> > > daemon when clicking on its close button?
> 
> > I think indeed that's what happens, because otherwise clicking there
> > would have shut down Emacs -- which it doesn't in the daemon case.
> 
> Yes, this is the case.  I would dearly like to find a way of determining
> if this last frame is still visible, or iconified, or whatever, as
> opposed to inaccessible.

I think this is the initial frame that exists in every Emacs session
when it starts, except that in the daemon we don't delete it.  It's a
non-GUI frame which exists just to keep code that expects some frame
to exist happy.

> The old frame in the above recipe was a -nw frame, effectively a
> TTY, and `frame-visible-p' returns t for it, even though it is not
> even displayable (it's containing shell has gone).

We don't have a means of knowing whether a TTY frame is displayed, it
conceptually always is.

> Hmm.  There is effectively nothing about the effect of Emacs as a daemon
> in Elisp.

There's nothing special about that, just some implementation details.