new default colors are unreadable in default environments

[elandorr]

eza v0.17.0 Just saw you went ahead on exa, nice! But the new default colors are wholly unreadable. Any chance you could add a flag to get the old ones back? Or better yet, make the RGB disco opt-in?

One of exa's benefits compared to the 9000 similar tools was/is that its defaults work. It works on lightweight, efficient terminals which don't support 24bit colors. Not on default xterm, which is black on white, but most are white/gray on black.

If used as an actual tool and not a toy for screenshots, you want the default to be readable and not fiddle with yet another config.

Happy new year's all!

[MartinFillon]

Any chance you could add a flag to get the old ones back

Not useful for me, but would be happy to provide you with the env variable necessary to colorate it well

[elandorr]

@rsholmes That's why I said "default environments". Defaults are almost always the same or close to historic precedent.

@MartinFillon If it's just a quick copy paste for you that'd be great, else don't bother for me.

The color selection itself is less of a problem than acknowledging that "more" is universally bad. There simply aren't many distinct color combinations.

The defaults from the last decades may not be screenshot-porn, but they were chosen for a reason. Almost every theme out there trades readability for style.

Unfortunately I don't have the time to showcase specific flags and situations highlighting this. If it's possible to copy paste the old defaults, that'd be great. Don't know how deep the color-hole goes.

[MartinFillon]

@elandorr I am really sorry, would love to be more helpful, but according to git history default have never been really changed (at least for the last 4 years) so that might more be due to an update from your terminal and its color handling or your manager. But if you want you can also take time and configure EZA_COLORS in your .{shell}rc file using this file, I am still available if you need help

[elandorr]

@martinfillon They changed.

Random sample:

In this case size + unit is all a single color now, brighter, though with more bleeding, but the dark blue on black became very hard to see.

It's a bit of a pain to not accidentally leak identifiable data or I'd have been collecting more screenshots.

That's a default lxterminal with "tango" for the record. But that does not matter anyway, because eza does not take all its color from the terminal's definition.

Slightly related: #315

[MartinFillon]

Ohhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh okay I didnt thought of those two indeed they changed, I thought you were talking about others, well the fix is simple

use --color-scale=age instead of just the arg itself, it will disable scaling on sizing

[elandorr]

I don't want to disable it, it is handy in exa. Disabling it for size would still incur the problem on age anyway.

exa doesn't scale dates. exa's scaling on size works well in default environments.

Same default environment as before:

exa: eza:

The random bold in there is also weird.

Date goes into contrast nirvana quickly and stays there, too:

eza expecting everyone to use a bloat terminal with 24 bit color support also breaks the colors unpredictably in e.g. urxvt (which even tries to find the closest value it can display):

To sum up:

• more colors than semantically useful = universally bad The visible spectrum does not offer many high contrast combinations.

• colors outside a 256 range = breaks randomly in all non 24 bit color terminals I.e. it wouldn't be very accessible even if the other problem didn't exist.

Solutions:

• Use the terminal's colors (very theme dependent, but worth an option)
• Pick from a predefined pool of max 256 colors that work reasonably well. An additional set for light colors if you want to be fancy. (Finding contrast there is even harder, though.)
• An additional set using only default 8 makes it even more accessible. See the previous link, someone already thought of this.

If colors were only changed in these two scales, this seems very fixable. Someone was motivated enough to complicate the color topic after all.

I hope this provides some inspiration.

[gospelranger]

This is also an issue for me, I use macos terminal.app xterm-256 color and the -color-scale-mode=gradient feature is completely broken for me. is there a way to use this feature outside of a 24-bit color terminal emulator? fixed mode appears pretty much the same to me as no scaling at all.

Is there a way to somehow override this with theme.yaml

thanks, love the bin overall