> Below with -Q reproduces the effect.
>
> (setq kill-buffer-quit-windows nil)
> (tab-bar-mode)
> (select-frame-set-input-focus (make-frame))
> (switch-to-buffer "FOO")
> (tab-bar-new-tab)
> (switch-to-buffer "BAR")
> ;; these emulate the effect I see
> (set-window-prev-buffers nil nil)
> (setq switch-to-prev-buffer-skip #'always)
The last two boil down to saying that the selected window is dedicated
to its buffer.
That might be in some way but window-dedicated-p returns nil for that case.
> (kill-buffer) ; frame is deleted when I expect the first tab to remain
> intact
>
> If the patch removes the test for window-dedicated-p, it leaves the first
> tab in place. I almost never use dedicated windows outside of a few
> packages that do but those haven't been in play vis-a-vis this issue. I
> don't pretend to fully understand what situation w-d-p is intended to deal
> with but if we can accommodate both, that'd be fine.
>
> ((and tab-bar-mode
(> (frame-parameter frame 'tab-bar-lines) 0) is more reliable.
> ;; Fall back to frame handling in case of less than 2 tabs
> (> (length (funcall tab-bar-tabs-function frame)) 1)
> ;; Close the tab with the initial window (bug#59862)
> (or (eq (nth 1 (window-parameter window 'quit-restore)) 'tab)
> ;; or with the dedicated window (bug#71386)
> (and ;; (window-dedicated-p window) ; <==== THIS WORKS BETTER
Agree that we don't need the strict window-dedicated-p condition?
I'd rather make this subject to an option say
'tab-bar-open-tab-inhibits-delete-frame'.
I assume you meant 'tab-bar-close-tab-inhibits-delete-frame'.
> (frame-root-window-p window)))
> ;; Don't close the tab if more windows were created explicitly
> (< (seq-count (lambda (w)
> (memq (car (window-parameter w 'quit-restore))
> '(window tab frame same)))
> (window-list-1 nil 'nomini))
> 2)
> )
> 'tab)