GNU bug report logs - #59721
30.0.50; tab bar groups are not ordered properly

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59721 in the body.
You can then email your comments to 59721 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 10:42:30 +0000

1. Enable tab-bar-mode and then alter tab-bar-format to show groups. Something like this:

  (setq tab-bar-format '(tab-bar-format-history tab-bar-format-tabs-groups tab-bar-separator tab-bar-format-add-tab))

2. Create three tabs: A, B, C. Now switch to A and use M-x tab-bar-change-tab-group and name it "foo". Now switch to C and name it "foo" also.

3. The tab bar groups are _not_ merged; with a large array of tab bars, this causes endless confusion as there are man duplicae tab groups. You would expect a tab group to coalesce like tab group members into a singular tab group --- that is after all their purpose.

This fixes it as I sort the entries before changing the frame parameter. 

(defun tab-bar-tabs-set (tabs &optional frame)
  "Set a list of TABS on the FRAME."
  (set-frame-parameter frame 'tabs (seq-sort-by (lambda (el) (alist-get 'group el nil))
                                                #'string-lessp
                                                tabs)))




In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
 3.24.20, cairo version 1.16.0) of 2022-11-29 built on mickey-work
Repository revision: 7939184f8e0370e7a3397d492812c6d202c2a193
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.3 LTS

Configured using:
 'configure --with-native-compilation --with-json --with-mailutils
 --without-compress-install --with-imagemagick CC=gcc-10'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2
M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE
XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_NUMERIC: en_GB.UTF-8
  value of $LC_TIME: en_GB.UTF-8
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: EL


Memory information:
((conses 16 1483854 167854)
 (symbols 48 84157 42)
 (strings 32 413180 15457)
 (string-bytes 1 12110186)
 (vectors 16 149413)
 (vector-slots 8 3697202 167267)
 (floats 8 844 449)
 (intervals 56 19443 3620)
 (buffers 992 60))

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

From: Juri Linkov <juri <at> linkov.net>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 59721 <at> debbugs.gnu.org
Subject: Re: bug#59721: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 18:38:57 +0200

> 1. Enable tab-bar-mode and then alter tab-bar-format to show groups. Something like this:
>
>   (setq tab-bar-format '(tab-bar-format-history tab-bar-format-tabs-groups tab-bar-separator tab-bar-format-add-tab))
>
> 2. Create three tabs: A, B, C.  Now switch to A and use M-x
> tab-bar-change-tab-group and name it "foo".  Now switch to C and name
> it "foo" also.
>
> 3. The tab bar groups are _not_ merged; with a large array of tab
> bars, this causes endless confusion as there are man duplicae tab
> groups.  You would expect a tab group to coalesce like tab group
> members into a singular tab group --- that is after all their purpose.

Thanks for the bug report.  We had a discussion about this problem
in the past, and in the result we arrived at such a solution that the
customizable variable `tab-bar-tab-post-change-group-functions' provides
an option `tab-bar-move-tab-to-group', so that when you select it,
then after changing the group name the tab is moved to its tab group.

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

From: Juri Linkov <juri <at> linkov.net>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 59721 <at> debbugs.gnu.org
Subject: Re: bug#59721: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 19:09:46 +0200

> I did not check if that solves it, but this issue --
> and how I discovered it -- manifests itself when you use
> `display-buffer-in-[new]-tab' and set a tab group that way.
>
> This can result in a large amount of distinct tab group entries for
> the same tab group; does `tab-bar-tab-post-change-group-functions'
> also resolve this?

Your guess is right.  After customizing this variable and using e.g.

(add-to-list 'display-buffer-alist
             '("buffer1" .
               (display-buffer-in-tab
                (tab-name . "C")
                (tab-group . "foo"))))

it merges the new tab with its group.

> Because just about anybody who'd use said display buffer action would
> find themselves in this predicament and that variable (and
> subsequently adding that function to it) is... unintuitive.

So you suggest to make this value the default?  Ok, the default value
will be changed in the release branch.

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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59721 <at> debbugs.gnu.org
Subject: Re: bug#59721: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 16:43:21 +0000

Juri Linkov <juri <at> linkov.net> writes:

>> 1. Enable tab-bar-mode and then alter tab-bar-format to show
>> groups. Something like this:
>>
>>   (setq tab-bar-format '(tab-bar-format-history
>> tab-bar-format-tabs-groups tab-bar-separator
>> tab-bar-format-add-tab))
>>
>> 2. Create three tabs: A, B, C.  Now switch to A and use M-x
>> tab-bar-change-tab-group and name it "foo".  Now switch to C and name
>> it "foo" also.
>>
>> 3. The tab bar groups are _not_ merged; with a large array of tab
>> bars, this causes endless confusion as there are man duplicae tab
>> groups.  You would expect a tab group to coalesce like tab group
>> members into a singular tab group --- that is after all their purpose.
>
> Thanks for the bug report.  We had a discussion about this problem
> in the past, and in the result we arrived at such a solution that the
> customizable variable `tab-bar-tab-post-change-group-functions' provides
> an option `tab-bar-move-tab-to-group', so that when you select it,
> then after changing the group name the tab is moved to its tab group.

I did not check if that solves it, but this issue -- and how I discovered it -- manifests itself when you use `display-buffer-in-[new]-tab' and set a tab group that way.

This can result in a large amount of distinct tab group entries for the same tab group; does `tab-bar-tab-post-change-group-functions' also resolve this?

Because just about anybody who'd use said display buffer action would find themselves in this predicament and that variable (and subsequently adding that function to it) is... unintuitive.

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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 59721 <at> debbugs.gnu.org
Subject: Re: bug#59721: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 18:41:48 +0000

Juri Linkov <juri <at> linkov.net> writes:

>> I did not check if that solves it, but this issue --
>> and how I discovered it -- manifests itself when you use
>> `display-buffer-in-[new]-tab' and set a tab group that way.
>>
>> This can result in a large amount of distinct tab group entries for
>> the same tab group; does `tab-bar-tab-post-change-group-functions'
>> also resolve this?
>
> Your guess is right.  After customizing this variable and using e.g.
>
> (add-to-list 'display-buffer-alist
>              '("buffer1" .
>                (display-buffer-in-tab
>                 (tab-name . "C")
>                 (tab-group . "foo"))))
>
> it merges the new tab with its group.
>

Good stuff. Thanks, Juri.

>> Because just about anybody who'd use said display buffer action would
>> find themselves in this predicament and that variable (and
>> subsequently adding that function to it) is... unintuitive.
>
> So you suggest to make this value the default?  Ok, the default value
> will be changed in the release branch.

I feel it's what people expect to happen -- what do you think?

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

From: Juri Linkov <juri <at> linkov.net>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 59721 <at> debbugs.gnu.org
Subject: Re: bug#59721: 30.0.50; tab bar groups are not ordered properly
Date: Wed, 30 Nov 2022 21:38:28 +0200

close 59721 29.1
thanks

>>> Because just about anybody who'd use said display buffer action would
>>> find themselves in this predicament and that variable (and
>>> subsequently adding that function to it) is... unintuitive.
>>
>> So you suggest to make this value the default?  Ok, the default value
>> will be changed in the release branch.
>
> I feel it's what people expect to happen -- what do you think?

I was unsure about this, but now that you raised this question, I agree
it would be natural for people to expect their groups don't get
scattered over the whole tab bar.  So now this is changed in emacs-29.

Thanks for suggesting this before the next release, so we had a chance
not to postpone this improvement for another release cycle.

Previous Next

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