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

Previous Next

Package: emacs;

Reported by: Al Haji-Ali <abdo.haji.ali <at> gmail.com>

Date: Thu, 6 Jun 2024 00:11:02 UTC

Severity: wishlist

Found in version 29.1

Fixed in version 31.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


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

From: martin rudalics <rudalics <at> gmx.at>
To: Al Haji-Ali <abdo.haji.ali <at> gmail.com>, Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 71386 <at> debbugs.gnu.org
Subject: Re: bug#71386: 29.1; Frame is auto-deleted even when it has multiple
 tabs
Date: Mon, 17 Jun 2024 18:47:08 +0200
> It would be great if the fix is done entirely in `window-deletable-p`,
> but is the idea functions in `window-deletable-functions` could have
> side-effects even though they are called from a predicate?

No.  We could emphasize that in the doc-string.  The idea is that such a
function can have 'window-deletable-p' return nil instead of 'frame' or
t.  WOW all functions on 'window-deletable-functions' have to agree that
'window-deletable-p' may return any non-nil value it initially proposes.

> For tabs, I believe an ideal fix would close the tab in lieu of
> deleting the frame when the buffer of a dedicated window is killed
> (similar to what Juri does in per patches).

The patch I proposed will simply cause another buffer to be shown in
that window.  How this affects the tab bar code is beyond the limits of
'quit-restore-window' and colleagues.  I suppose the tab bar code should
do whatever it does when 'switch-to-prev-buffer' gets called.

martin




This bug report was last modified 35 days ago.

Previous Next


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