Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Fri, Mar 19, 2021 at 14:33:20 +0200, Eli Zaretskii wrote:
> > 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.

Yes, I think that's right.

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

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.

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

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

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

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

OK, thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).