GNU bug report logs -
#71386
29.1; Frame is auto-deleted even when it has multiple tabs
Previous Next
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 #241 received at 71386 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Apr 2, 2025 at 3:00 AM Juri Linkov <juri <at> 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 34 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.