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

[Eli Zaretskii <eliz@gnu.org>]

> 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?