GNU bug report logs - #62427
tab-bar-new-tab-to now handles cases with multiple side-windows

Previous Next

Package: emacs;

Reported by: Benson Chu <bensonchu457 <at> fastmail.com>

Date: Fri, 24 Mar 2023 21:14:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 62427 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 62427 <at> debbugs.gnu.org, bensonchu457 <at> fastmail.com
Subject: Re: bug#62427: tab-bar-new-tab-to now handles cases with multiple
 side-windows
Date: Sun, 26 Mar 2023 07:19:12 +0300
> Cc: 62427 <at> debbugs.gnu.org
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sat, 25 Mar 2023 21:14:24 +0200
> 
> > 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?

(Also, the patch's commit log message is not according to our
conventions, but that's a minor issue.)




This bug report was last modified 2 years and 27 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.