Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii]

> Date: Sat, 20 Mar 2021 10:28:26 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > 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.
> 
> This initial frame gets used as a normal frame when one calls
> 
>     $ emacsclient foo
> 
> for the first time.

Are you sure?  ISTR that we create a new frame on the terminal from
which emacsclient was invoked.  The initial frame is never used except
at startup and when the daemon should do something while it has no
clients.

> It stays in use until one clicks on its close
> button (I think this is actually the close button of the containing
> xterm).  When a new GUI frame is brought up by
> 
>     M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
> 
> , the initial frame may or may not have been "closed" by clicking its
> close button.  I think you're telling me that it's not possible to
> distinguish these two cases.  If so, that's surely a defect in Emacs.

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

> > We don't have a means of knowing whether a TTY frame is displayed, it
> > conceptually always is.
> 
> Perhaps we should create some means of knowing this?  Maybe in
> handle-delete-frame, where Emacs has determined there is only one frame
> left, before calling save-buffers-kill-emacs we could mark the last
> frame's f->visible to "not visible".

You mean, for a frame that is about to be deleted anyway? what purpose
would that serve?