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

Previous Next

Full log

Message #160 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 <at> linkov.net
Subject: Re: bug#71386: 29.1;
 Frame is auto-deleted even when it has multiple tabs
Date: Sun, 30 Mar 2025 09:02:12 -0400

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

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

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Sun, 30 Mar 2025 08:35:35 -0400
> > Cc: Juri Linkov <juri <at> linkov.net>, 71386 <at> debbugs.gnu.org,
> rudalics <at> gmx.at,
> >       abdo.haji.ali <at> gmail.com
> >
> >  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.
>
> When the window is not dedicated to its buffer?  That shouldn't
> happen: replacing a buffer in windows does NOT delete a window if it
> is not dedicated to the buffer being replaced, and consequently the
> frame should NOT be deleted in that case.
>

I thought you meant explicitly made dedicated via set-window-dedicated-p or
a display-buffer-alist action.  This case is just a "regular" window
dedicated to its buffer, yes.

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.
>
> That's how Emacs behaves.  Tabs don't change that.
>

Right.  That's what's being discussed.

> '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.
>
> I think the situation discussed here is sufficiently similar.
>

Perhaps it is similar in spirit, but it's different use case.  In the
controversial case, there aren't any window configurations to restore
because the frame is (controversially and unexpectedly) deleted.

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