On Sun, Mar 30, 2025 at 3:43 AM Eli Zaretskii wrote: > > From: Juri Linkov > > Cc: 71386@debbugs.gnu.org, martin rudalics , Eli > > Zaretskii , 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.