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 08:25:10 +0300

severity 71386 wishlist
thanks

> From: Ship Mints <[email-masked]>
> Date: Sat, 29 Mar 2025 19:11:40 -0400
> Cc: martin rudalics <[email-masked]>, Eli Zaretskii <[email-masked]>, Juri Linkov <[email-masked]>, 
> 	[email-masked]
> 
> 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.

The tab-bar tabs are just the visual representation of saved
window-configuration objects.  replace-buffer-in-windows never
supported selecting one of the available window-configurations to
replace the buffer shown in the single dedicated window of a frame.
Conceptually, I don't see any relation between these two features, and
no reason up front why replace-buffer-in-windows should select another
tab when a window is deleted because the buffer to which it is
dedicated is removed from display.

Also, the behavior you describe to delete the frame is only when the
window is dedicated to its buffer.  Is that what happened in your
scenario?

We have already a user option tab-bar-select-restore-windows; did you
try to customize it to get the effect you want?

In any case, I converted this bug report into a feature request, since
I don't see a bug in the behavior you describe.