Re: Some minor suggestions to Tab Bar

[Juri Linkov <juri@linkov.net>]

> 2. Add new faces for group tabs. The idea is to differentiate these 2
> cases:
>   2.1. Tabs from the current group X tabs from other groups
>   2.2. Regular tabs X collapsed group tabs
>
> It's not possible to know which tabs belongs to the current group or
> which tabs represent another group, since all inactive tabs use the same
> face 'tab-bar-tab-inactive'. I did a slight modification to
> 'tab-bar-tab-name-format-default' and 'tab-bar-tab-group-format-default'
> to add two new faces:
>
> In the example above (please desconsider the styles I used), we can see
> that:
>   * [1], [2] and [8] are tabs that do not belong to any group (ungrouped)
>   * [3] is a collapsed group tab of a group named "group1", where tab
>     [4] belongs to the same group and is hidden
>   * [5] and [7] are tabs that belongs to the current group (same group)
>   * [6] is the current active tab

While adding a new face for groups and using it instead of tab-bar-tab-inactive
is easy to do, the real problem is what to do with inactive ungrouped tabs.
To highlight them differently with some dimmed out face, we need first
to detect whether any group is already in use.  Because when groups
are not used, then displaying ungrouped tabs differently makes no sense.
Do you have an idea how to handle such case?

> 3. Add a new user option to set a default group for new tabs
> ('tab-line-new-tab-default-group'). When nil, the behavior is the same
> of today where new tabs are ungrouped. If a string, new tabs are
> assigned automatically to that group. If a function, it's called to
> return the group name for the new tab. The "initial tab" is also
> affected, so after setting this new user option and enabling
> 'tab-bar-mode', the first tab and subsequent new tabs will be assigned
> to the default group.

This is now pushed as the option 'tab-bar-new-tab-group'.

> 4. Today, the group name is not copied when 'tab-bar-duplicate-tab' is
> called, so the user needs to type 'C-x t n' to duplicate the tab and
> 'C-x t G' to set the same group name of the tab it was duplicated
> from. It would be nice if 'tab-bar-duplicate-tab' could also duplicate
> the group name.

A new let-binding '(tab-bar-new-tab-group t)' was added to 'tab-bar-duplicate-tab'.

> 5. When I first played around with tab bar groups, I created several
> tabs and assigned groups to them in a non sequential order, e.g.:
>
>  [1 group1 AAA] [2 group1 BBB] [3 CCC] [4 group1 DDD] [5 group2 EEE]
>
> Then I noticed a "strange" behavior and thought this feature was not
> working properly. After adjusting the group order so all tabs of the
> same group are next to each other (e.g., setting group1 to tab 3 or
> removing group1 from tab 4), it worked as expected. I don't know "if" or
> "how" this specific case of non sequential group tabs should be handled,

Currently the user needs to arrange tabs manually to make all group tabs
adjacent.  It's possible to do this automatically.  For example, in
Chromium-based web browsers adding the current tab to the group
changes the position of the tab to be closer to other tabs of the same group.
While it makes some sense, moving the tab without user's consent
is not a good thing to do.  Maybe this behavior of automatically moving
the tab closer to tabs of the same group could be optional?

> but that's something we could clarify in the documentation.

Please suggest where and how this could be explained in the documentation?

> If someone find these ideas useful, I can send patches.

Thanks, your patches and more ideas are highly appreciated.