Replace fixed colors by named ones so that it works well with any color scheme

[ariasuni]

fix #359 (when using --colo[u]r-scale)
fix #338
fix #363

For --colo[u]r-scale, I used distinct values a bit like k zsh script., it’s much more readable and so useful.

[ariasuni]

Right now this code doesn’t touch the logic. I think it’s better if the unit has the same color as the number before it when using --colo[u]r-scale.

[ariasuni]

Now, size and unit is displayed with the same color when --colo[u]r-scale is used.

(and I changed the message of the first commit).

[ariasuni]

Oops I messed up a git push --force… will push my missing commits again when I’ll be back home.

[ariasuni]

Since it is such a small fix, I also added the missing word in the fish completion script.

[rugk]

May this be included? It would also solve a long-standing issue as it seems?
What is still missing about this old PR, @ogham? (you already assigned it…)

[ariasuni]

Can you @ogham copy/paste our discussion by e-mail, or do you allow me to do so?

Edit: updated my code so that it could be merged automatically.

[rugk]

Uh, does that mean this may finally getting reality (i.e. merged) here? 🎉

[ariasuni]

@ogham said:

[…] I’d like more command-line programs to use the full range of terminal features that are common these days, such as 256 or 24-bit colours, and because I never found the right colour for ‘medium grey’ that worked well across terminals, I picked one from the 256 colour set. My thinking is that including it by default means other programs will start using these features too.
[…], I’d like to make a new commit based off your code, turning it into a built-in colour theme that users can set with an environment variable. exa will keep using 256 colours by default, only it will be much easier for people to disable if they need to.

my answer:

My main issue with the current state of exa and your proposed solution is that by default, exa’s output is unreadable on some configurations (particularly with light themes but not only), and I tend to think default configuration should work for as much people as possible, in order for them to have a good first experience with exa.

So it may not be merged as is, but will be available at some point.

[SethMMorton]

I want to echo @ariasuni's most recent comment about a good first impression being important and the current configuration being unreadable. I tested out exa because I wanted to install it for my team of about 200 engineers, but on my very first test I saw something that looks like this (image from #425 (comment)) and knew that there was no way this tool would be adopted.

It's not enough to just have an amazing feature set... the output also has to be readable.

[ogham]

@SethMMorton I just commented this on the linked thread, but I'll repeat it here: that shade of blue is extremely annoying. exa has to pick between dropping a colour from the base palette of just 16, or being unreadable for people who use the default theme for their terminal.

In a way, it's the opposite of the problem described in this issue. The dark blue is a configurable terminal colour, not one of the fixed 256 colours that you can't change. I really recommend changing it because it's an old default that's slowly being replaced with a more readable blue. I wrote more about this decision over here: https://bsago.me/blue

[ogham]

Anyway, I think I owe you all (especially @ariasuni) an explanation over why I've dragged my feet on this PR.

I can see the argument for restricting exa to using the base 16-colour palette by default. exa almost does this already: common file kinds and the --long columns use them, because they're the ones that are used by everybody all the time. The only holdouts are the following:

1. The colours used for the --colour-scale file sizes.
2. The colours used for certain file extensions such as music or videos or pictures or documents.
3. The grey colour used for punctuation, dashes, tree hierarchy, etc.

For the file sizes, I thought it would be better if the colours for each size were unique, so the column is still recognisable as a file size column (it's why so many of them were green, or green-ish). And for the file extensions, I started running out of colours to use, so I started picking ones from the extended palette. I was fairly sure that I picked "safe" fixed colours, but I have heard people saying otherwise, and it does make sense for exa's default theme to use safe colours. So I'm willing to acquiesce on (1) and (2) and drop down to using 16 colours for file sizes and types.

But the grey punctuation colour? This is where I am stuck. There is no good default colour that can fill this role while working well on both light and dark terminals:

Either it's unreadably dim, or it's too much, but Grey Number 244 is perfectly in the middle. I've seen black bold used for greys in the past (and I've used it myself in many scripts), but it's not without its problems: some terminals will bold the text as well as brightening it, which has the opposite effect — I want to fade the text, not bold it! There's also a dim setting, which sounds like just what I need, but it's not as widely-implemented as 256 colours are.

My opinion is that it's OK to use a fixed colour for punctuation because it's a shade of grey, and thus works well with many themes. I also (still!) plan on including more built-in themes by default, including a pure 16-colour one and a more crazy 256-colour one.

Does that sound like an acceptable way forward?

[ariasuni]

My issue right now is that I can’t use EXA_COLORS to reproduce (entirely) what I did with this PR.

If I can setup without too much trouble exa (i.e. not by setting a very longEXA_COLORS) so that it never use fixed colors, then it’s perfect for me and other users that carefully chose the colors of their terminal.

I do not really have an opinion on the default colors used by exa since I don’t want to use them, so I trust your vision.

I would be glad to help anyway but I don’t know how you want to implement that. It seems to me that we should be able to tell exa what color to use for what type of file (e.g. image, audio, etc.).

[ericbn]

@ogham, having defaults with the basic 16 terminal colors seem to be a good move into sane defaults that will work on a wider variety of environments. And talking about variety of environments, let me add a note on that: I suggest dropping the 04 blue color and only using bold blue instead of that, so dropping the number of used colors to actually 15. And I've read your very well written article on the blue terminal color! :- )

The 04 blue terminal color is so annoying that, for the sake of having sane defaults, you should avoid it as part of the defaults IMO.

In our community-maintained set of Zsh modules, we've decided to to that. For reference into the rabbit hole, some discussions we had are here and here.

I'm not saying "nobody should use the 04 blue color", I'm more specifically suggesting "don't include it in the default color scheme, and use bold blue instead".

[romkatv]

@ericbn When you say that using bold blue is OK, do you mean color 12 or color 4 with bold attribute? Color 12 isn't blue in some popular color schemes. For example, in Solarized 12 is grey and 13 is blue. Only the first 8 colors have predictable hues (black, red, green, yellow, etc.). 4 with bold attribute can be rendered as color 4 on some terminals and as color 12 on others. Better terminals have a setting to allow users choice.

Your deciding to avoid color 4 in zimfw is an interesting choice. Is your preference a majority opinion?

[ericbn]

EDIT: Updated after comments below.

Hi @romkatv. The decision to avoid color 4 was based on the majority opinion, and we didn't get complains about the blue color since then (Dec 1, 2017).

And I'm making the suggestion here targeting CLI tools, and exa more specifically. I'm not sure if these would apply to prompt themes (see note below).

Good point on the 8-15 colors: I avoid them too exactly because Solarized has different/non-matching colors there (as you described). I would suggest only using the 0-7 colors with bold attribute instead. Now, if those will be rendered as the given color with a bold font or as the given color with value + 8, it depends on the terminal capability/settings (as you well described too). This of course limits the background colors that can be picked.

So summarizing, the colors I suggest for CLI tools sane defaults are only:

• 0-3 or 5-7 (avoid 4 and the 8-15 colors)
• 0-7 with with bold attribute (4 with bold attribute is fine, as it will be usually shown as color 12 on those same setups where users didn't bother to pick a better 4 color and/or enable bold fonts). These of course do not apply as background colors.

Bottom line: users won't complain "that blue bold color does not look nice" because there's no other blue better than that! :- ) Using 12 instead of 4 with bold will force a gray color on Solarized instead of a highlighted blue color, so not an option either.

NOTE: One could still think about using 4 as a background color with a foreground different than 0, but that has the risk of being an indistinguishable background color on a dark terminal. So to keep the suggestions strict, I suggest avoiding 4 for background too. None of these suggestions here are initially intended for prompt themes. Prompt themes can have a closer relationship to color schemes -- Agnoster itself suggests Solarized for example. If exa wants to target a wider audience than those who also care about customizing their color schemes, then my suggestions stand.

[romkatv]

Hi @romkatv. The decision to avoid color 4 was based on the majority opinion, and we didn't get complains about the blue color since then (Dec 1, 2017).

When you say "majority opinion", do you mean of those who'd commented on zimfw PRs?

I respect your choice to avoid color 4 in zimfw but it's not very popular in the broader zsh community, is it? The most popular zsh themes, in no particular order, are robbyrussel (the default theme in Oh My Zsh), pure, agnoster, powerlevel9k, powerlevel10k, spaceship and starship. Collectively they have at least 2 orders of magnitude more users than all zimfw themes combined (a rather conservative estimate). All of them use color 4 in their default configurations. Spaceship uses bold 4 (its whole prompt is bold) and so does starship -- the reimplementation of spaceship in rust. The rest use regular color 4.

This isn't to say that I'm suggesting that you change anything in zimfw. It would be presumptions of me to do so. If anything, it would be exciting to see if zimfw picks up more users thanks to its blue abstinence.

[ericbn]

Hi @romkatv, yes only using color 4 along with the bold attribute in our utility module (that adds color to ls, grep and less), and our git module (that adds custom git log formats with color) was the consensus of the people who commented on the PRs. I didn't think a wide poll was required to decide that at the time. But when I read an article on the blue color like the one @ogham wrote, or see people still complaining about color 4, it makes me thing it was a good decision.

My intention with my first comment here -- since @ogham previously declared how annoying the color 4 can be with his article -- was to suggest only using color 4 along with the bold attribute from the exa default color schemes.

My suggestion was not intended to prompt themes. I made a side note on my second comment giving the example of Agnoster, that uses color 4 as background while it also suggests it's best seen with Solarized colors, in order to indicate how prompt themes and color schemes can relate to each other. In this sense, I believe tools like exa target a wider audience than prompt themes, and I also mean it from the perspective of environments where users would use them. For example, it would not be simple to change the colors of a FreeBSD I have running in VMware. I might still like installing exa there, but I probably will be fine with having a simpler prompt theme.

Let me rephrase my second comment so it does not sound like it was directed specifically to Powerlevel10k or prompt themes in general.

[ariasuni]

exa is unmaintained, and this has been done in the active fork eza.