Hacker News Reader

Comment by twic | Hacker News Reader

> I have to admit I don't really get this. I personally like colorized output, and I can't even think of situations where the colors chosen by a developer were so bad I wanted to disable them completely.

There's a few programs i use where the colours were clearly chosen to work on a dark theme terminal. I use a light theme terminal, and they're illegible.

I suppose the real problem here is that the output is tagged with physical colour, rather than some kind of semantic label which could be mapped to a colour in terminal configuration. But it's probably too late to do anything about that.

View on HN

Don't most terminal emulators allow you to set your own color palette? So what would show up as yellow text on a normal black background, you could change to show up as maybe as gold? Obviously it would mess with the meaning behind why the developer chose that particular color (like red errors, yellow or orange warnings) but I'm sure you'd get used to it.

There’s a few different sets of ansi escape sequences for managing colour. The ones you’re on about are the 8/16 colour palette. Unfortunately there is a trend these days for developers to use 8-bit (256 colours) pallet or even the true colour (24-bit). Both of the latter are not customisable in the terminal.

Coincidentally I’ve gone into rants a number of times in the past on here about developers not using the correct colour palettes and the answer I always receive back for why it’s ok is because “developers should be able to chose how their application looks like”, which is fine if they control the entire design stack like they would on a website. But it makes zero sense in the terminal.

That makes sense. I've been wondering if we've been doing something subtly awkward with our internal tooling. However, most are just using the 8 or 16 color palette with a simple convention like "Use red (or technically, color 1, which just happens to be red for us) as error, yellow as warning, green as success" and let the terminal theme and the user figure out how it should look on their screen.

Interesting, I didn't realize both kinds of control characters existed

[checks the color library I'm currently using to build a CLI]

Even though my terminal lets me do that, I’d rather just disable colors on some programs that choose poorly than spend time configuring that. I like your basic red=failure stuff so I don’t want to disable color entirely but I’m not going to spend time tweaking just because some joker decided dark blue on black looks neat.

That configuration would be at the terminal level, but it would potentially need to be different for each program. The default ls colours are fine, and i don't want to change them, but the colours in our internal package management tool are broken, and i do.

Given the existence of shell pipelines, i might even want different palettes within a single stream of output, so this mapping couldn't even be done by hooking command execution to apply a different mapping in the terminal.

As the GP says, the problem is when the color is specified as RGB triples by the software.

I find it's more of a problem when applications use the color palette instead of 24-bit color. Someone might pick foreground and background colors that contrast perfectly well in their 8 color palette, but that in mine are impossible to distinguish. And changing them for one case might break legibility somewhere else. When the colors come from the 24-bit RGB selection, contrast will always be as the author intended.

I've had that problem with the default LS_COLORS/DIR_COLORS settings in some Linux installs. It's very annoying.

If your palette does not have good contrast between foreground colors 31-37 and background color 40, that's on you. If you cange the default background color to something other than 40 that's also on you - if you want the default background to be white, change the palette so that color 40 is white (instead of changing the backgound color to e.g. 47) and make the foreground colors dark enough so that they contrast well.

Guilty [1]. But it's really hard to handle both light and dark color themes! On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme. Some color schemes intentionally invert the "bright" colors and makes them darker for a light colored scheme. This is what Gruvbox [2] does, but most other palettes don't. I also have an issue with Solarized which makes some of the Bright colors almost exactly the same as the foreground or background, which can make text printed in certain colors seem invisible.

I've used ANSI codes to invert colors (which works pretty well for highlighting), and dim colors, but those can't solve everything.

[1]: https://github.com/PaulJuliusMartinez/jless/issues/4 [2]: https://github.com/morhetz/gruvbox

The design intent for Solarized is to minimize contrast, so this may lie somewhere between “you’re holding it wrong” territory, and aggressive cargo-culting advertising making this theme show up everywhere as an implied default good option. It is a nice set of color choices, but is not really appropriate for many situations where it gets used.

Especially when no environment variable tells you whether to use light or dark.

The terminal itself can be queried. https://www.talisman.org/~erlkonig/documents/xterm-color-que...

> On a dark terminal you're probably more likely to use the "Bright" variants when using the default 16 color palette, but then you'll have less contrast in a light theme.

The bright theme should invert the "dark" and "light" colors.

The physical colors are what the terminal configuration maps to. At least, modern terminals that I've used since the DOS era. Even back then, I had a tiny utility that I used to set the EGA palette for different text-mode programs. Amberscale tones on a deep low-saturation blue was one of my favorites.

Obviously won't help if you're using a teletype or punched cards or something like that.

IME most programs still use the 8 traditional ANSI colors, which are exactly that (labels mapped to actual colors through config).

The problem here is that the 8 (or 16) ANSI colors are labels for just that: colors. 0 for black, 1 for red, etc. What OP is suggesting is more "abstract" labels, probably like "error" or "warning". More akin to text editor themes, which assign colors to particular semantic groups.

The labels are abstract. You can make them whatever color you want. Basically every terminal theme does this.

Perhaps in theory. Almost every application under the sun I've encountered expects 1 to be red, or 4 to be blue, or 3 to be yellow, or whatever.

As an example, take solarized, or really any of the base16 themes. When I've used solarized in the past, many terminal programs that expect to print something in red are actually printing in a slightly-dimmed-background color, or purple, or something else where the intention of the tool author and the intention of the theme author conflict.

The abstraction level is not high enough. As labels goes, color1 doesn't have the same semantic strength than error_color.

The less you know about them, the higher the abstraction. A program can distribute meaning over colorN in any way it wants. Any fixed semantic mapping would prove insufficient in the universe of all possible programs.

Reply on news.ycombinator.com