GNU bug report logs - #71386
29.1; Frame is auto-deleted even when it has multiple tabs

Previous Next

Full log

View this message in rfc822 format

From: Ship Mints <shipmints <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, abdo.haji.ali <at> gmail.com, 71386 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#71386: 29.1; Frame is auto-deleted even when it has multiple tabs
Date: Mon, 31 Mar 2025 11:29:50 -0400

[Message part 1 (text/plain, inline)]

On Mon, Mar 31, 2025 at 11:09 AM martin rudalics <rudalics <at> gmx.at> 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)
>
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.