Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Wed, Mar 17, 2021 at 22:19:10 +0200, Eli Zaretskii wrote:
> > Date: Wed, 17 Mar 2021 21:55:38 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no, emacs-devel@gnu.org

> > > This could be difficult to fix.  I don't think that clicking on the last
> > > frame's close button goes through `delete-frame' - it just closes the
> > > program, whether that's emacs or emacsclient.

> > I'm not sure I understand completely what you say here, but clicking
> > on the frame's close button does invoke delete-frame, see the handling
> > of DELETE_FRAME_EVENT in keyboard.c.

> And if you are talking about the last live frame of an Emacs session,
> then look at handle-delete-frame, which is called when you click that
> close button: it will call save-buffers-kill-emacs (which has a hook)
> and then kill-emacs (which also has a hook).

Thank you, that is very helpful.  I was indeed talking about the last
live frame, specifically in an emacsclient session when the Emacs daemon
is running.

The problem that Miha highlighted is that when there is an open
minibuffer when that last frame is deleted, that open minibuffer remains
in existence, fouling up the next emacsclient session.

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.

Incidentally, there doesn't seem to be anything in the Elisp manual
about the handling of Emacs daemon sessions.

-- 
Alan Mackenzie (Nuremberg, Germany).