Re: Stop frames stealing eachothers' minibuffers!

[Alan Mackenzie]

Hello, Eli.

On Fri, Mar 19, 2021 at 17:59:45 +0200, Eli Zaretskii wrote:
> > Date: Fri, 19 Mar 2021 15:35:13 +0000
> > Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, jakanakaevangeli@chiru.no,
> >   emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> Can't you move them from those inaccessible frames to this one?

The actual moving of the minibuffers isn't the problem ....

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

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

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

> 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".  Or maybe set up a special non-zero
dummy value for f->terminal.  Or something like that.

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

> There's nothing special about that, just some implementation details.

OK.  I'm not sure I agree, but it's not really a big point.

-- 
Alan Mackenzie (Nuremberg, Germany).