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

From: Ship Mints <[email-masked]>
Date: Sun, 30 Mar 2025 09:02:12 -0400

On Sun, Mar 30, 2025 at 8:56 AM Eli Zaretskii <[email-masked]> wrote:

> > From: Ship Mints <[email-masked]>
> > Date: Sun, 30 Mar 2025 08:35:35 -0400
> > Cc: Juri Linkov <[email-masked]>, [email-masked],
> [email-masked],
> >       [email-masked]
> >
> >  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.