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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 30 Mar 2025 15:55:42 +0300

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

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.

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