bug#62427: tab-bar-new-tab-to now handles cases with multiple side-windows

[Benson Chu <bensonchu457@fastmail.com>]

> Ugh!  That is _soooo_ inelegant...  Also inefficient

Hehe, I see what you mean, but creating frames is so expensive. These
tabs are like lightweight frames for me. What would you suggest be done
instead?

> Is this inside unwind-protect, so that any error or quit or throw is
> caught and the parameters restored?  If so, it might be semi-okay.

Ahhh, that is a good point. The reason I even noticed this error was
that there wasn't an unwind-protect around it, so not only would Emacs
not switch to a new tab, but my window paramters for the current tab
would be all messed up.

> What does display-buffer do in this case? reuse the same window
> regardless of any action alists?

Huh, that is a gooood question. I will look into what #'display-buffer
does.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Benson Chu <bensonchu457@fastmail.com>
>> Cc: juri@linkov.net, 62427@debbugs.gnu.org
>> Date: Tue, 28 Mar 2023 11:17:29 -0500
>>
>> > Can't we create a completely new window and show the buffer in it?
>>
>> I'm not sure how easy this is. Typically new windows come from calls to
>> #'split-window, and you can't do that for a side-window.
>
> What does display-buffer do in this case? reuse the same window
> regardless of any action alists?
>
>> >                            I'm very uncomfortable with removing window
>> > parameters like that.  These windows don't belong to us, right?
>>
>> Let me know if this is wrong, but I am interpreting this statement as:
>>
>> "We shouldn't be modifying the window parameters of the windows that
>> belong to the old tab."
>
> There doesn't have to be any "old tab".  AFAIU, this option's default
> value is t, so even when you create the first tab, the code you
> suggest changing will run and mess with the window parameters of the
> windows that happen to exist at that point.  Right?
>
>> Because if that's the case, we're not /really/ modifying the old tab's
>> window-parameters. They're only "removed" "temporarily", for the
>> purposes of creating the new tab. You can see right before we modify any
>> window parameters, we make a call to (tab-bar--tab), which returns a tab
>> data structure, which contain a representation of the current wconf
>> (window configuration) - effectively saving the wconf - including the
>> paramaters. It's kind of like a save excursion:
>>
>> (let ((old-tab-num (tab-bar--current-tab-index tabs))
>>       (old-window-configuration (tab-bar--tab)))
>>   ;; modify window-parameters
>>   ;; do appropriate splitting
>>   ;; Now we have the window layout for the new tab
>>
>>   ;; The old tab should have the old-window-configuration
>>   (setf (nth old-tab-num tabs) old-window-configuration)
>>
>>   ;; The rest of the function
>>   )
>
> Is this inside unwind-protect, so that any error or quit or throw is
> caught and the parameters restored?  If so, it might be semi-okay.
>
>> So, we capture the current window configuration at the start of the
>> function, transition the current window configuration into the window
>> configuration for the new tab (which involves mangling window
>> parameters and destroying windows), then we make sure that the old tab
>> has an unmodified window-configuration.
>
> Ugh!  That is _soooo_ inelegant...  Also inefficient, and quite
> fragile (as any code which uses seve/restore window-configuration is).
> But I guess that ship has sailed long ago.
>
>> When the user switches back to the tab they left, all the
>> window-parameters are still present, untouched. Are you still
>> uncomfortable with doing things this way?
>
> What happens with all kinds of hooks that run due to this saving and
> restoring window-configuration? they still will see windows without
> their parameters, right?