> From: Ship Mints <shipmints@gmail.com>
> Date: Sun, 30 Mar 2025 08:35:35 -0400
> Cc: Juri Linkov <juri@linkov.net>, 71386@debbugs.gnu.org, rudalics@gmx.at,
> abdo.haji.ali@gmail.com
>
> 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.