Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Mar 18, 2021 at 20:44:12 +0200, Eli Zaretskii wrote:
> > Date: Thu, 18 Mar 2021 16:58:25 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>, monnier@iro.umontreal.ca,
> >   jakanakaevangeli@chiru.no, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > >  >> Maybe such open minibuffers should just be aborted (along with any other
> > >  >> recursive edits) when the last frame gets deleted.  This would be
> > >  >> simpler to code than preserving those minibuffers somewhere, and
> > >  >> restoring them at the next emacsclient session.  Aborting them also
> > >  >> seems more natural, since their contents are unlikely to have any
> > >  >> relevance to the next emacsclient session.

> > >  > Martin, can you comment on this, please?

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

> If the former, we need to ask all those questions before we shut down
> Emacs.  Why is it a problem to ask them?

Sorry, I didn't mean to imply these things were problems; it was just an
observation, comparing the question about unsaved buffers with the lack
of a question on open minibuffers.

In the following, I'm using my not yet committed version of minibuf.c,
etc.:

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.  The minibuffers are stored in the frames'
->minibuffer_window components, as well as existing as buffers in their
own right.  When the last frame is deleted, I would expect the MB to
survive, but NOT to be put back into the mini window of the newly
created frame.

Could it be that the last frame isn't actually deleted from the Emacs
daemon when clicking on its close button?  Merely that the emacsclient
program is closed, leaving its window inactive/invisible/whatever?  In
fact running M-: (frame-list) shows two frames, one of which is called "
*Minibuf-1*", though it isn't displayed in X-Windows.

This is the sort of thing I would like to be able to read about in the
Elisp manual, along with basic questions like "How can one test whether
one is in an emacsclient session rather than an ordinary Emacs?".

-- 
Alan Mackenzie (Nuremberg, Germany).