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

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: bensonchu457@fastmail.com,  62427@debbugs.gnu.org
> Date: Mon, 27 Mar 2023 10:05:40 +0300
> 
> >> > I've noticed that when I call #'tab-bar-new-tab while I'm in a
> >> > side-window that has siblings, I get an error from
> >> > #'window--sides-check, which happens when #'tab-bar-new-tab calls
> >> > #'delete-other-windows. Here's an example of my problem:
> >> > ...
> >> > The attached patch fixes this issue. Could it be applied to the emacs-29
> >> > branch?
> >>
> >> Thanks.  Unless Eli has objections, I'd like to push the patch
> >> to the emacs-29 branch since it correctly fixes the problem.
> >
> > I'd like first to understand better the code involved and the
> > suggested change in it.  Just reading the code of tab-bar-new-tab-to,
> > it looks strange.  Why does tab-bar.el care about "window parameters
> > that can cause problems with 'delete-other-windows' and
> > 'split-window'" to begin with?  And why removing these parameters from
> > windows is TRT for tab-bar.el to resolve such problems, when it
> > doesn't really "own" those windows?
> 
> Indeed, maybe 'delete-other-windows' and `split-window'
> should handle these cases.  So since the patch fixes the bug,
> it could be pushed to emacs-29.  Then in master
> 'delete-other-windows' and `split-window' could be rewritten
> to handle the 'window-side' parameter.

Maybe I'll agree, but I still don't understand the problem well
enough.  Would you please explain the original problem that led
tab-bar.el to care about these window parameters?

TIA