On Wed, Apr 2, 2025 at 4:48 PM Ship Mints <shipmints@gmail.com> wrote:

> On Wed, Apr 2, 2025 at 3:00 AM Juri Linkov <juri@linkov.net> 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)?

-Stephane