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

Previous Next

Full log

Message #38 received at 71386 <at> debbugs.gnu.org (full text, mbox):

From: Al Haji-Ali <abdo.haji.ali <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 71386 <at> debbugs.gnu.org
Subject: Re: bug#71386: 29.1; Frame is auto-deleted even when it has
 multiple tabs
Date: Fri, 07 Jun 2024 19:44:45 +0100

On 07/06/2024, Juri Linkov wrote:
> Ok, here is a better patch:

Hello Juri,

If I may interject a bit, I think it would be better if the tab is closed (i.e., tab-bar-close-tab is called) and another tab is displayed when the dedicated buffer is killed if its the only one in a window. For example, I changed `window--delete` on my machine to have this

(if (and tab-bar-mode
         (> (length (tab-bar-tabs)) 1))
    (tab-bar-close-tab)
  (delete-frame frame))

In your patch, `tab-bar-window-delete-frame-p` doesn't do that, nor should it as it is a predicate. Maybe `window-delete-frame-predicate-functions` should be renamed to `window-delete-frame-actions` or something and `tab-bar-close-tab` should be called in `tab-bar-window-delete-frame-p` (removing `-p` probably) -- in fact, the `delete-frame` code itself could be added as such an action, if we are not averse to changes to the interface.

Also, just FYI, your patch doesn't allow the branches with `auto-hide-function` and `frame-auto-hide-function` to be called when `kill` is nil. I don't know the side-effects of not calling these functions in such cases, but might be worth checking.

-- Al

Previous Next

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