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

From: Ship Mints <[email-masked]>
Date: Sun, 30 Mar 2025 21:37:40 -0400

On Sun, Mar 30, 2025 at 10:38 AM Ship Mints <[email-masked]> wrote:

> On Sun, Mar 30, 2025 at 9:55 AM martin rudalics <[email-masked]> wrote:
>
>>  > I'll give it a try.  I have a question, though, and sorry if the
>> answer is
>>  > obvious.  Where is the window parameter 'quit-restore get set 'tab to
>> begin
>>  > with?
>>
>> At the very end of 'display-buffer-record-window'
>>
>>     ((eq type 'tab)
>>      ;; WINDOW has been created on a new tab.
>>      (set-window-parameter
>>       window 'quit-restore
>>       (list 'tab 'tab (selected-window) buffer)))))
>>
>> I suppose.  The initial call is from 'display-buffer-in-new-tab'.
>>
>
> Makes sense.  Thank you.  I don't use those display actions.  Juri's patch
> should address the main issue for both use cases.  I hope to try it out
> later today.
>
> Minor point...when reading through the code, I think the docstrings for
> 'window--display-buffer' and 'display-buffer-record-window' need to add
> 'tab to the TYPE section in each.
>

Hi, Juri,

[The patch probably needs to be rebased on master but I was able to apply
it by hand, I think.]

The conditions it's testing for are not ones that exist in my case.

The conditions are:

I'm not using the display actions in my configuration and I don't invoke
the tab-bar functions that use it.

I have two tabs on a newly opened frame.  Both tabs have only one window.
If I'm on tab 2, and I eval (kill-buffer), the frame disappears.

>From inside window-deletable-p: tab-bar-mode=t #tabs=2 quit-restore
parameter=nil window-dedicated-p=nil frame-root-window=t

HTH (hope that helps and happy to help),

-Stephane