* bug#59721: 30.0.50; tab bar groups are not ordered properly
@ 2022-11-30 10:42 Mickey Petersen
2022-11-30 16:38 ` Juri Linkov
0 siblings, 1 reply; 6+ messages in thread
From: Mickey Petersen @ 2022-11-30 10:42 UTC (permalink / raw)
To: 59721
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))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#59721: 30.0.50; tab bar groups are not ordered properly
2022-11-30 10:42 bug#59721: 30.0.50; tab bar groups are not ordered properly Mickey Petersen
@ 2022-11-30 16:38 ` Juri Linkov
2022-11-30 16:43 ` Mickey Petersen
0 siblings, 1 reply; 6+ messages in thread
From: Juri Linkov @ 2022-11-30 16:38 UTC (permalink / raw)
To: Mickey Petersen; +Cc: 59721
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#59721: 30.0.50; tab bar groups are not ordered properly
2022-11-30 16:38 ` Juri Linkov
@ 2022-11-30 16:43 ` Mickey Petersen
2022-11-30 17:09 ` Juri Linkov
0 siblings, 1 reply; 6+ messages in thread
From: Mickey Petersen @ 2022-11-30 16:43 UTC (permalink / raw)
To: Juri Linkov; +Cc: 59721
Juri Linkov <juri@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#59721: 30.0.50; tab bar groups are not ordered properly
2022-11-30 16:43 ` Mickey Petersen
@ 2022-11-30 17:09 ` Juri Linkov
2022-11-30 18:41 ` Mickey Petersen
0 siblings, 1 reply; 6+ messages in thread
From: Juri Linkov @ 2022-11-30 17:09 UTC (permalink / raw)
To: Mickey Petersen; +Cc: 59721
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#59721: 30.0.50; tab bar groups are not ordered properly
2022-11-30 17:09 ` Juri Linkov
@ 2022-11-30 18:41 ` Mickey Petersen
2022-11-30 19:38 ` Juri Linkov
0 siblings, 1 reply; 6+ messages in thread
From: Mickey Petersen @ 2022-11-30 18:41 UTC (permalink / raw)
To: Juri Linkov; +Cc: 59721
Juri Linkov <juri@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?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#59721: 30.0.50; tab bar groups are not ordered properly
2022-11-30 18:41 ` Mickey Petersen
@ 2022-11-30 19:38 ` Juri Linkov
0 siblings, 0 replies; 6+ messages in thread
From: Juri Linkov @ 2022-11-30 19:38 UTC (permalink / raw)
To: Mickey Petersen; +Cc: 59721
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-11-30 19:38 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-30 10:42 bug#59721: 30.0.50; tab bar groups are not ordered properly Mickey Petersen
2022-11-30 16:38 ` Juri Linkov
2022-11-30 16:43 ` Mickey Petersen
2022-11-30 17:09 ` Juri Linkov
2022-11-30 18:41 ` Mickey Petersen
2022-11-30 19:38 ` Juri Linkov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).