Subject: bug#71386: 29.1; Frame is auto-deleted even when it has multiple tabs

From: Ship Mints <[email-masked]>
Date: Fri, 4 Apr 2025 13:28:24 -0400

On Fri, Apr 4, 2025 at 12:32 PM Juri Linkov <[email-masked]> wrote:

> >         >         > 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?
>

Aha that was a different bug number so it wasn't immediately apparent it
was the same.  It seems, then, that all I need is to submit a patch to
amend tab-bar-tests.el with the one that represents the use case we've been
discussing?  If so, it's attached.

-Stephane