On Mon, Mar 31, 2025 at 11:09 AM martin rudalics wrote: > > 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. > I leave this up to Juri. > ;; 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) > >