GNU bug report logs - #71386
29.1; Frame is auto-deleted even when it has multiple tabs

Previous Next

Full log

Message #151 received at 71386 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, abdo.haji.ali <at> gmail.com, 71386 <at> debbugs.gnu.org,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#71386: 29.1;
 Frame is auto-deleted even when it has multiple tabs
Date: Sun, 30 Mar 2025 08:35:35 -0400

[Message part 1 (text/plain, inline)]

On Sun, Mar 30, 2025 at 3:43 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Juri Linkov <juri <at> linkov.net>
> > Cc: 71386 <at> debbugs.gnu.org,  martin rudalics <rudalics <at> gmx.at>,  Eli
> >  Zaretskii <eliz <at> gnu.org>,  abdo.haji.ali <at> gmail.com
> > Date: Sun, 30 Mar 2025 09:35:09 +0300
> >
> > > I've been bitten by this same issue where kill-buffer /
> > > replace-buffer-in-windows doesn't take available tab-bar tabs into
> > > consideration as viable replacement windows to restore when quitting
> the
> > > last window on a frame.  I looked at 29+, 30, 31 window.el/.c and
> > > tab-bar.el and I can't find if this was resolved or if there was a
> recipe
> > > to avoid this.
> > >
> > > I've resorted to wrapping kill-buffer using a custom function, not
> advice,
> > > to inhibit deleting the frame.
> > >
> > > Do any of you recall if this bug was addressed and how?  If not, may I
> > > assist in some way?
> >
> > Sorry, I'm still testing the fix attached below.
> > Does it work for you?
>
> As I wrote, I don't understand what does deleting a window have to do
> with tab-bar.  Can you explain why this is conceptually reasonable as
> the default behavior?
>

Because users have implicit expectations of what a frame's behavior
should be in the presence of multiple tabs?  One condition contrary to my
expectations are: more than one tab "open" (yes, I know they aren't
"real"), the current window configuration (aka current tab) has a single
(non-dedicated) window with one buffer, no window prev-buffers.  If that
sole buffer gets killed, the frame is deleted.  Docs for
'replace-buffer-in-windows' say "If that window is the only window on its
frame, delete its frame when there are other frames left [on the
terminal]."  However, the concept of "only window" when a user has implied
windows in other dormant tabs, makes this behavior bothersome.

'tab-bar-select-restore-windows' addresses a wholly different problem where
a window configuration is set and a buffer referenced in the configuration
is now no longer live.

[Message part 2 (text/html, inline)]

Previous Next

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