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

> Cc: [email protected]
> Date: Fri, 07 Aug 2026 14:06:54 -0400
> From: Aaron Zeng via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[email protected]>
> 
> When Emacs is started as a daemon:
> $ emacs -Q --daemon
> $ emacsclient -nw
> 
> 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'.

Thanks.  When you know which commit caused the issue you are
reporting, please always CC the author(s) of that commit (by using the
"X-Debbugs-Cc" header, see admin/notes/bugtracker).  This will make
our lives as Emacs maintainers a tad easier, and avoid unnecessary
almost-duplicate messages, such as this one, where all I do is CC
Martin.

> 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?).  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, but I didn't attempt to change that because it seemed
> likely to be necessary for some internal reason.)
> 
> 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.

Martin, any comments?

And why is this change not in NEWS?