Re: Stop frames stealing eachothers' minibuffers!

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 19 Mar 2021 11:40:52 +0000
> Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > > What about answering questions about unsaved buffers, running processes
> > > > ...  in such a situation?  I never use emacsclient so I have no idea how
> > > > this should behave in practice.
> 
> > > I don't use emacsclient either.  But questions about unsaved buffers
> > > seem to prevent Emacs terminating until they get answered.  The same for
> > > running processes (at least, for gdb).
> 
> > Are we shutting down Emacs, or are we returning to a headless daemon
> > state?
> 
> Returning to a headless daemon state.

Then I think there's no need to ask those questions at all.  Emacs is
not going away, so it's okay to leave unsaved edits in the session
that continues to run.

> When I now try Miha's recipe:
>    (In last frame of emacsclient:)
>    M-: (run-at-time 10 nil #'make-frame '((window-system . x)))
>    C-x C-f foo
>    Close the frame by clicking on its close button
>    <Wait the remainder of the 10 seconds>
> 
> , 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?

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

> This is the sort of thing I would like to be able to read about in the
> Elisp manual

You expect the ELisp manual to describe the internals to this detail?
That's stuff for comments in the code (adding which will be very
welcome), not for the ELisp reference.

> along with basic questions like "How can one test whether one is in
> an emacsclient session rather than an ordinary Emacs?".

This seems to be a matter of improving indexing: see the variable
mode-line-client and how it is computed.