> From: Juri Linkov <juri@linkov.net>
> Cc: 71386@debbugs.gnu.org, martin rudalics <rudalics@gmx.at>, Eli
> Zaretskii <eliz@gnu.org>, abdo.haji.ali@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.