Tab group faces need further distinction

[alphapapa]

Hi Prot,

I've been experimenting with Emacs 27+ tab-bar features, and I noticed that, when using tab-bar groups, the face of a tab group is the same as that of a grouped, active tab, so the two types of tab (a group tab and an tab within the group) can't be distinguished.

For example, here's what the tab bar looks like with a selected tab group, with the faces as defined by modus-operandi:

The first white tab is a tab group, currently selected, and the second white tab is the selected tab within that group. But since they look the same, it's not obvious that they are actually two different kinds of tab, and that one is within the group defined by the first one.

After enabling boxes for the tab-group faces, it looks like this:

Now the group tab has a box, so it can be distinguished from the selected tab within its group.

I don't know if using boxes is the best way to distinguish group tabs from non-group tabs; it looks good to me, but I'll leave that decision up to you. :)

Thanks for your work on these themes!

[protesilaos]

Hello @alphapapa and thanks for reporting this!

Yes, that is clearly a problem and I will check it right away. Will report back to you.

[protesilaos]

Hello again!

I think there are two ways to approach this: (1) use a foreground colour for the group names, but otherwise let them look like the active/inactive tabs, or (2) use background colours for the groups which will make them stand out more.

In the following screenshots I also include modus-vivendi as well as the variants when modus-themes-tabs-accented is non-nil. Just for the sake of completeness.

Foreground only

We use a blue colour for the groups. The active group has the same background as the active tab. Inactive groups have the same background as inactive tabs.

Backgrounds

Active groups use a blue background. Inactive groups use a blue tint by default and a gray value when modus-themes-tabs-accented is non-nil. The latter case is so that the user may not conflate groups with tabs (it is a small touch, but I think it's effective).

Concluding thoughts

Option 1 is more subtle. I feel it works better when there is a multitude of groups and tabs. The main problem with this presentation is that the foreground colour can be mistaken for some kind of activity. As if there is a running process in a tab. Kind of how it happens when you push to Magit, or do something like C-x v L, and get a status indicator on the mode line.

Option 2 is clearer, though it might look too busy as the number of tabs+groups increases. Its upside is that it will not be mistaken for some transient indicator or warning. Its only potential downside is that it could be interpreted as a mouse hover highlight, though I feel that is easy to avoid given the context and how the mouse pointer moves (also because tabs do not seem to respond to mouse hover events like the mode line, links, etc.).

As such, I am inclined to go with option 2. What do you think?

Alternatively (or additionally), we could introduce a user option: modus-themes-tabs, which will supersede modus-themes-tabs-accented. Its default would be the gray background for tab-bar and the option 2 for the groups. It would accept a list of properties, like this:

;; accented background for the bar, default style for the group names
(setq modus-themes-tabs '(accented))

;; default background for the bar, foreground-only for the group names
(setq modus-themes-tabs '(groups-subtle))

;; accented background for the bar, foreground-only for the group names
(setq modus-themes-tabs '(accented groups-subtle))

;; and possibly other properties, like `bold', `italic'

[alphapapa]

Hi Prot,

Thanks for your, as always, thorough consideration. It's not an easy decision between those two options. Using the background color does present a better distinction, but IMHO the bold blue background color feels a bit overwhelming in the unaccented screenshots. At the same time, I can see how the foreground-only option might not be distinctive enough in some cases. So if it's not too much trouble (or code to maintain), I suppose I'd vote for the third option, allowing users to choose the style they prefer.

[protesilaos]

Thanks for your, as always, thorough consideration. It's not an easy decision between those two options. Using the background color does present a better distinction, but IMHO the bold blue background color feels a bit overwhelming in the unaccented screenshots.

I agree. That blue was not designed to be a background---and it shows. We may need new colours for this context. Though I must test whether we have alternatives first.

At the same time, I can see how the foreground-only option might not be distinctive enough in some cases. So if it's not too much trouble (or code to maintain), I suppose I'd vote for the third option, allowing users to choose the style they prefer.

Yes, that is what I plan to do by introducing the option modus-themes-tabs. It will accept a list of composable properties, each of which adds some style. For example (symbols are tentative):

;; accented background for the bar, default style for the group names
(setq modus-themes-tabs '(accented))

;; default background for the bar, foreground-only for the group names
(setq modus-themes-tabs '(groups-subtle))

;; accented background for the bar, foreground-only for the group names
(setq modus-themes-tabs '(accented groups-subtle))

;; and possibly other properties, like `bold', `italic', `underline' (I will test)
(setq modus-themes-tabs '(accented groups-subtle bold))

Once I start experimenting with it, things will be clear and I will be able to share more screenshots. Expect a status update this evening (local time is ~9h).

[protesilaos]

Hello again Adam!

I experimented with the idea of modus-themes-tabs and ultimately decided not to implement it. I thought that many of the possible styles would not be suitable for the task:

• Italics are used in the tab-line (different, I know) to denote buffers that do not have an underlying file. It could thus cause confusion as to what the same presentation means in the tab-bar. We could say that tab-bar groups are also special in that they do not visit any file, but they also are not tabs either. Feels like that is too much nuance to pack into an italicised font.

• An overline is barely visible in certain contexts, such as when the Emacs frame is set to fullscreen. Unlike a :box attribute, overlines are only 1px thick, so the accent colours they can use on top of the varying shades of gray background are too few and not good enough for our purposes.

• Underlines have the same problems as overlines, with the addition that they are drawn under the text, not the lowest part of the rectangle that holds the text (like an outer margin).

• Adding more bespoke colours for the groups does not suffice. I experimented with multiple new shades of gray, lighter/darker accent colours. They all imposed considerable constraints. If we use a shade of blue for active tabs, even if we agree on the right colour value, we must find another for the inactive tabs that appears to be less intense. But then making it "less intense" may ultimately bring it too close to the colour of inactive tabs, to the effect that the distinction between a tab and a group is unclear. Same principle for shades of gray.

So I decided to go with what you showed at the beginning of this thread: a :box style. I have implemented a fairly subtle border and otherwise left the group names look like tabs (an active group does not have a bold weight though, to not draw too much attention to itself).

Please let me know what you think and whether there is something else we could do or which I did not consider.

Below are the screenshots:

Default style

Default groups side-by-side

Accented tabs

Accented groups side-by-side

[alphapapa]

Hi Prot,

I'm always impressed by how carefully you make these design decisions. :)

* Italics are used in the `tab-line` (different, I know) to denote buffers that do not have an underlying file.

I'm glad you noticed that (I'm the one who added that feature, and Juri wasn't sure if it was worth it or would be confusing, but he didn't object to it). ;)

I think the box-based style is a good choice. Looking at the most recent screenshots you posted, I feel like the box in the screenshot I posted, with a thicker line, is easier to distinguish; the thinner box line almost requires looking carefully to discern it against the other colors in the tab bar, and I can imagine that some users might have trouble seeing it. And going forward, that might be even more important on high-DPI displays. So, if possible, using a 2-pixel box line might be nice.

I've already learned a lot about modus-themes just from this issue (I wasn't aware of the customization, accenting, etc). :)

[protesilaos]

I'm glad you noticed that (I'm the one who added that feature, and Juri wasn't sure if it was worth it or would be confusing, but he didn't object to it). ;)

I think it is a useful addition in its own right. Perhaps we should have the equivalent for the tab-bar.

As for our case, it is important to be mindful of how the metaphors we use apply in similar contexts. Theme-wide consistency is more difficult to get right, though I feel it contributes to a more streamlined experience when done properly. The nuanced insight here is to know when to suspend the application of one's own rules and why: consistency for its own sake can lead to suboptimal results.

I think the box-based style is a good choice. Looking at the most recent screenshots you posted, I feel like the box in the screenshot I posted, with a thicker line, is easier to distinguish; the thinner box line almost requires looking carefully to discern it against the other colors in the tab bar, and I can imagine that some users might have trouble seeing it. And going forward, that might be even more important on high-DPI displays. So, if possible, using a 2-pixel box line might be nice.

Very well! What do you think about this, though?

 modus-themes.el | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/modus-themes.el b/modus-themes.el
index c2c26a4..583a33d 100644
--- a/modus-themes.el
+++ b/modus-themes.el
@@ -7265,9 +7265,9 @@ ;;;;; tab-bar-groups
 ;;;;; tab-bar-mode
     `(tab-bar ((,class ,@(modus-themes--tab bg-active bg-active-accent nil nil nil nil t))))
     `(tab-bar-tab-group-current ((,class ,@(modus-themes--tab bg-tab-active)
-                                         :box (:line-width (1 . -1) :color "gray50"))))
+                                         :box (:line-width (2 . -1) :color "gray50"))))
     `(tab-bar-tab-group-inactive ((,class ,@(modus-themes--tab bg-tab-inactive bg-tab-inactive-accent fg-dim)
-                                          :box (:line-width (1 . -1) :color "gray50"))))
+                                          :box (:line-width (2 . -1) :color "gray50"))))
     `(tab-bar-tab ((,class ,@(modus-themes--tab bg-tab-active nil nil nil t t))))
     `(tab-bar-tab-inactive ((,class ,@(modus-themes--tab bg-tab-inactive bg-tab-inactive-accent fg-dim nil t))))
 ;;;;; tab-line-mode

The standard 2px is like :line-width 2. Though it has the side effect of marginally increasing the height of the bar. Whereas :line-width (2 . -1) avoids that. Is the result good enough for you? Or do you prefer the standard style? I always prioritise usability over aesthetics such as this one: it just is that I am not sure here---whatever you think works best.

[ the syntax for the :box is found in (info "(elisp) Face Attributes") ]

[alphapapa]

I think it is a useful addition in its own right. Perhaps we should have the equivalent for the tab-bar.

That's a good idea. What would it apply to?

consistency for its own sake can lead to suboptimal results.

Yes, "A foolish consistency is the hobgoblin of little minds." ;)

The standard 2px is like :line-width 2. Though it has the side effect of marginally increasing the height of the bar. Whereas :line-width (2 . -1) avoids that.

That's interesting: on my system, using Emacs 28.0.50 built within the past week, I can set the HWIDTH of the box to up to 2 pixels without increasing the height of the tab bar. In other words, there's no difference in appearance between an HWIDTH set to 2 and one set to -2. I wonder if that's because of my default face's font, which is:

'(default ((t (:height 105 :family "Fantasque Sans Mono"))))

Anyway, I agree that we should avoid increasing the tab bar height with this change, because that would cause it to change when a group tab is added. I think the appearance is better using a 2-pixel HWIDTH to match the VWIDTH, but if it's necessary to use -1 or -2 for the HWIDTH as a default, so be it. :)

[protesilaos]

That's a good idea. What would it apply to?

The name of the tab-bar tab typically matches that of the current buffer. So it could be italicised when, say, the buffer does not visit a file. Same principle as tab-line-tab-special.

Another feature of the tab-line is the alternating backgrounds for inactive tabs. I see no obvious reason why that cannot work for the tab-bar (at least in terms of presentation, as I don't know about the code).

Yes, "A foolish consistency is the hobgoblin of little minds." ;)

Nice!

Anyway, I agree that we should avoid increasing the tab bar height with this change, because that would cause it to change when a group tab is added. I think the appearance is better using a 2-pixel HWIDTH to match the VWIDTH, but if it's necessary to use -1 or -2 for the HWIDTH as a default, so be it. :)

My mistake! I forgot to update it in my previous samples. The new commit has :line-width (2 . -2).

---

By the way, thanks again for the feedback. I maintain an "Acknowledgements" section in the themes' manual. Added your name there under the heading "Ideas and user feedback".

[alphapapa]

The name of the tab-bar tab typically matches that of the current buffer. So it could be italicised when, say, the buffer does not visit a file. Same principle as tab-line-tab-special.

That's not a bad idea.

Another feature of the tab-line is the alternating backgrounds for inactive tabs. I see no obvious reason why that cannot work for the tab-bar (at least in terms of presentation, as I don't know about the code).

Yes, I also implemented that feature. :) (Thanks for reminding me, actually, because it's not the default in Emacs 28.0.50, and I forgot to turn it on in my 28 config.)

And, yes, it wouldn't be hard to implement that for tab-bar tabs too.

My mistake! I forgot to update it in my previous samples. The new commit has :line-width (2 . -2).

Oh, ok. Well, IIUC my comment applies to that as well, so I guess my conclusion is the same. :)

By the way, thanks again for the feedback. I maintain an "Acknowledgements" section in the themes' manual. Added your name there under the heading "Ideas and user feedback".

Thanks, that's kind of you. Those names are good company to be listed among. :)

[protesilaos]

Hello again, Adam!

(this is about tab bar groups needing further distinction with the modus-themes)

I believe we had finalised this, but I forgot to close the issue. Do you think there is anything else left?

[alphapapa]

I don't think so. Thanks, Prot. :)

[protesilaos]

I don't think so. Thanks, Prot. :)

You are welcome! And thanks again for taking the time to help me with this!

…

-- Protesilaos Stavrou https://protesilaos.com