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: Juri Linkov <juri <at> linkov.net>
To: Ship Mints <shipmints <at> gmail.com>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>, abdo.haji.ali <at> gmail.com, 71386 <at> debbugs.gnu.org
Subject: bug#71386: 29.1; Frame is auto-deleted even when it has multiple tabs
Date: Fri, 04 Apr 2025 19:30:33 +0300

>         >         > WIP patch attached with a test and some few refinements
>         we've
>         >         talked about
>         >         > in this dialog.  I didn't alter tab-bar-mode to
>         tab-bar-lines as
>         >         Martin
>         >         > suggested.  You're the expert.
>         >
>         >         We don't need a new unusable option, so please remove it
>         and submit
>         >         a new patch.
>         >         Also please replace tab-bar-mode with tab-bar-lines like
>         Martin
>         >         suggested.
>         >         Then everything should be good.  Also it seems you forgot
>         to remove
>         >         window-dedicated-p in your previous patch.
>         >
>         >     I'll work on that now.  I'll remove
>         >     'window-delete-active-tabs-inhibit-delete-frame'. 
>         'window-dedicated-p'
>         >     condition now gone.
>         >
>         >     Are you sure you don't want this to support the case where
>         tab-bar-mode
>         >     is active and tabs merely aren't visible?
>         >
>         > There's also 'tab-bar--tab-bar-lines-for-frame' if you think
>         that's more
>         > appropriate.
>
>         'tab-bar--tab-bar-lines-for-frame' is used to set tab-bar-lines,
>         but you need only to get it.
>
>         > All tests pass unless I set tab-bar-show nil, and I still think
>         this patch
>         > should work even if the tab-bar is hidden, but tab-bar-mode is
>         enabled.
>
>         It's a different situation when you see tabs like in a web browser.
>         They have even an option "Ask before closing multiple tabs".
>         We could add a similar option instead of the above one,
>         with 3 possible values like
>
>         1. nil - don't ask and close all tabs
>         2. t - close only the current tab
>         3. 'ask - ask a confirmation
>
>     Hmm.  Well Emacs isn't a web browser, but I hear you.  I'll try out an
>     option like that and see how it feels.  I haven't looked deeply, but if
>     we prompt inside window functions and there are state changes along the
>     code path before the prompt that we can't undo if the user quits while
>     prompted, I don't think we need that level of complexity.  Maybe we can
>     prompt before state changes using window-deletable-p output as an
>     indication.  Again, not looked that deeply yet.
>
> As I guessed, it's not easy to find the right place(s) to put a prompt
> before state changed or undoing state is easy.  May I suggest that we move
> ahead with the patch I've attached and consider enhancements that may
> include a prompt at a later time?  We can also see how people get on with
> the tab-bar-lines condition vs. just tab-bar-mode (which I still prefer)?

Sorry, this was fixed yesterday following Martin's request in bug#59862.
I've cc-ed you a mail about this, but maybe you missed it?
Could you please update your patch from current master?

Previous Next

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