I’m the author of a terminal emulator so I regret to say that I know far too much about this cursed subject.

I’ll start with saying this article is excellent. There is no “but” to that, I just want to add some extra information in case Julia (big fan, by the way) or anyone else is interested. I’d also like to ask for feedback: as the author of a terminal emulator, I’d love to hear from anyone on ideas to improve things. One thing I’m immediately thinking based on this article is: I need to make minimum contrast better and more obvious that it exists. I’m noodling on it. But happy to hear anything else.

A note on TERM: by setting it to xterm (or frequently xterm-256color), you’re effectively telling whatever is running that the terminal running supports all the features of xterm. This does get you pretty colors usually but you will also sacrifice some modern features that programs MAY (but shouldn’t) use “TERM” for: Kitty keyboard protocol, synchronized output, styled/colored underlines, and more. Admittedly, if you’re SSHing into a machine, these may not be very useful anyways so it’s fine but just so you know if you’re using a modern terminal some stuff may stop working.

I said above “MAY (but shouldn’t)”, so what should they do? The most modern well supported thing to do is XTGETTCAP. This is more or less terminfo but via VT sequences instead of an environment variable and local database. As a result, it works over SSH and without any SSH config madness. Besides XTGETTCAP, some sequences (like Kitty keyboard protocol and synchronized output) have feature test sequences that noop on unsupported terminals.

Did I say cursed subject? Cursed subject.

Beyond that, I’m trying to help this subject slightly: my terminal provides a terminal inspector (grep “inspector”) which is like a “web inspector.” You can hover over cells and see exactly what color they are set to (both RGB and palette numbers). You can also see things like the active palette. I mainly want to help answer the question “why the #&!* is this cell this way?” (amongst other questions).

So to close it out: I’d love to hear any ideas people have for improving this. I too want people to more easily get things “zero config” out of the box that just works. I think finding a way to make minimum contrast work by default without being jarring is one thing I’m thinking about. But I’m open to other ideas, too.

And again, big fan of Julia Evans!

Ignoring all the instruction encoding idiocy abound – The fundamental problem is that colouring already starts with the developer side saying ‘ok I think this should be red’ and then the emulator side going, nah, ‘red is green’ rather than semantically tagging ‘text is red, line-drawing is white, …’.

Then you side-step all of this with the three or four added instructions for setting colours from a (possibly downsampled) 8 bit r/g/b or sixel encoded ‘can we embed an image in a way that makes dot matrix printers feel accurate by comparison’ way where applying a scheme suddenly become the equivalent of tone mapping.

I’m not sure why the iTerm Solarized theme is designed this way (there must be a reason!) but I’m pretty sure I prefer the version where the “bright” colours are actually colours instead of all being shades of gray.

This is actually as originally specified by Ethan Schoonover, the designer of Solarized, who used it as a way of fitting the larger set of “base” tones into the 16 slots afforded by ANSI colors. See the table entitled “The Values” on the website: https://ethanschoonover.com/solarized/#the-values

I used to use base16-shell + base16-vim, but I didn’t like the actual syntax aspect of the color scheme – in terms of what colors were chosen for different highlight groups. (See https://github.com/tinted-theming/home/issues/10). For the curious, there’s also been a community fork of Chris Kempson’s original base16 work, since he seemed to have gone inactive: https://github.com/tinted-theming

I finally ended up going off the deep end of color scheme nerdery, formulated my own from scratch, set up neovim and iTerm to use it, and have thankfully resisted the urge to fiddle with it much further. (https://github.com/e-q/okcolors.nvim)

As an every day terminal user for 25+ years, my approach is to simply stick to the default 16 colors.

If an app shows me yellow text on a white background, I consider this an issue with the app, not something to fix by reconfiguring my terminal and breaking other apps in the process.

If the terminal’s default colors deviate too much from the standard VGA (looking at you, Gnome Terminal), THEN I consider this an issue with the terminal. But my solution is to switch to a different one, instead of tinkering with the config.

The reason is that I use several different machines, with a few different operating systems, from which I ssh to several dozens of remote instances, some of them shared with other developers. Hence I prefer to adjust myself to a set of default shells, editors and colors, rather than spend time perfecting my configs on every machine.

To be honest I also find the 16 default colors just enough for nice and clear TUIs, and personally never really felt the need for more of them. At least I can see much more important usability issues with terminal apps than colors.

This is my favorite way to visualize the 16 colors:

#!/usr/bin/env perl

for ( [ 0 .. 7 ], [ 8 .. 15 ] ) {
    printf "\x1b[48;5;${_}m %2d ", $_ for @$_;
    print "\x1b[0m\n";
}

[Comment removed by author]

I’ve recently started setting my system to greyscale (for sort of unrelated reasons), and it’s very nice that it solves the problem of aesthetically-clashing colours. It doesn’t solve the problem of colour combos with insufficient contrast, but it might help a bit because it means that any old solution will do.

Problem one listed there, blue on black and yellow on white, annoyed me enough to write my own terminal emulator. Mine uses a classic palette, but when drawing, if a cell has poor contrast, it adapts the colors to make it legible again Screenshot to show: https://arsdnet.net/terminal-colors.png I also special case white on white and black on black to make them grey instead, still fairly low contrast, but it is readable (sorry i messed up the label once in the screenshot but you can still see the idea).

It arguably could still be better, but this is an approach I’m surprised more terminal emulators don’t adopt.

I hit a bunch of these problems, and after trying pretty much every color scheme I could find, I ended up making my own color scheme that fixes some of these issue. It’s likely to be impossible to fix all of them though. We use that theme (Aardvark Blue) for most of the Ratatui demos. In particular it solves the blue on black, blue on default background, light yellow on gray (but not bright white).

Originally added to the iTerm2 color schemes library in https://github.com/mbadolato/iTerm2-Color-Schemes/pull/417

The goal of this theme was:

• colors are fairly natural (i.e. blue is blue, red is red)
• background and black are distinct
• grays are naturally ordered avoiding full black
• light and dark colors are distinct from each other
• all colors look good on background, black, dark gray, gray, white

Demo screenshot in https://ratatui.rs/examples/style/colors/ (which btw is a pretty nice utility for checking out contrast themes when you’re going through the process of choosing them)