bug#81575: 31.0.91; Regression in window-deletable-p when Emacs is started as a daemon

 >> Previously, (window-deletable-p) returned nil when there was only a
 >> single window in the one-and-only emacsclient frame.  In bd647f36,
 >> this behavior changed so that (window-deletable-p) returns `frame'.

IIUC 'window-deletable-p' only does what its doc-string said before:

   Return `frame' if WINDOW is the root window of its frame and that
   frame can be safely deleted.

The decision whether a frame can be deleted safely is made in
'frame-deletable-p'.

 >> I believe the previous behavior was correct, and matches the intended
 >> use of this function (namely, may a frame be deleted implicitly by
 >> some other operation?).

I can't tell about "implicitly" the emphasis being on "safely".

 >> The attached patch restores the previous
 >> behavior in this situation.  (FWIW it's sort of confusing that the
 >> initial frame is considered visible for the purpose of
 >> frame-visible-p,

Is it?  I have never looked into this before and it seems like an
obvious bug to me.  I don't use emacsclient.

 >> but I didn't attempt to change that because it seemed
 >> likely to be necessary for some internal reason.)

Does anyone have an idea why this would be needed?  It means that
uses of 'frame-visible-p' can be bogus when running emacsclient.

 >> For context on the downstream effect, a user at my site reported a
 >> regression with the vterm-toggle package which uses window-deletable-p
 >> to decide how to "dispose of" the window displaying a vterm buffer
 >> when the process exits:
 >>
 >>      (if (eq vterm-toggle-reset-window-configration-after-exit 'kill-window-only)
 >>          (cond
 >>           ((eq (window-deletable-p) 'frame)
 >>            (delete-frame))
 >>           ((eq (window-deletable-p) t)
 >>            (delete-window))
 >>           (t
 >>            (quit-window)))
 >>
 >> I think the above snippet is sensible and should be made to continue
 >> to work.

I can't tell what the semantics of the condition is but the remainder
looks sensible to me.

So summing this up: This bug is actually about not deleting the last
non-initial frame of emacsclient because we are erroneously told that the
initial frame is visible.  Right?

I looked into the patch you posted and I think it's reasonable to
install on the release branch.  But I'd strongly recommend to either fix
the visibility state of the initial frame or amend the doc of
'frame-visible-p' accordingly.  If 'frame-visible-p' can return non-nil
for an invisible frame, we have a very big problem.  And this time it's
not the window manager that causes it.

 > Martin, any comments?
 >
 > And why is this change not in NEWS?

Which change?  Both 'window-deletable-functions' and 'frame-deletable-p'
are in NEWS.

martin