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

From: Juri Linkov <[email-masked]>
Date: Thu, 03 Apr 2025 09:54:04 +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.

Why not:

1. C-x 5 5 M-x eww
2. C-x t t M-x eww
3. q
4. q

behaves as expected from a web browser.

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

Agreed, we don't need that level of complexity and don't need an option.
I don't think anybody might want the first 'q' in the above scenario
to delete the whole frame.