As long as CLI programs stick to the 8 or 16 standard colors and refrain from setting background colors (inverse mode is fine), as well as from explicitly setting white or black as text color, everyone can reasonably configure their terminal colors so that everything is readable.
When going beyond that, the colors really need to be configurable on the application.
Use only default (white/black), red for bad, green for good. If you need more than that, like vim or whatever, then maybe a 'fullscreen' TUI is better, with a specified background and foreground. For CLI tools, I'm not sure if I prefer more colours.
The CSS to make the terminals look like iTerm was smooth, to the point I read them as screenshots.
8% of men of Northern European descent (and 0.4% of women) are red-green colorblind. That'd be a terrible choice. Use blue-orange, blue-red, or purple-green.
A confused user once stopped by, they had a blank terminal, so I showed them how to select all which revealed the helpfully black on black text. These days I compile colour support out of st, or set *colorMode:false for xterm. "But you can customize the colours" is a typical response, to which one might respond that one has grown weary of pushing that particular rock, and moreover one may be busy with other things at a drag-out monitor in a server room at three in the morning that has helpfully dark blue text on a black console, or worse if some high-minded expert has gone and rubbed the backside of a unicorn everywhere so that they may improve the "legibility".
Colourful terminals are so useful. I have mine colour coded according to the working directory depending on the project. So I can see which terminal is associated with which project even if there are twenty terminals open. The scripts are even in my servers so when I ssh in to them it changes colour as well.
There's an ever more basic rule: don't just make your text white (ANSI 37m) because you assume the terminal will have a dark background. Even white-on-black (37;40m), while usually readable, can stand out the wrong way if you assume that everyone is using dark mode.
IMO if your terminal theme does not provide high contrast for "white" text on the default or "black" backgrounds, that's for you to fix. If you want a light terminal then change the color scheme to map "black" to a bright color and "white" to a dark color while making sure that other colors have good contrast to your "black". Don't just change the default foreground and background color and expect every single color using program to fix your mess.
That's a funny example. I have no issues with the idea of course but in my day to day life I'm way more likely to encounter an issue with colors being lost after sent to a pager or a log file or tee or what not
Funny thing, those are not "the usual places" I've ever heard of, and I care somewhat about color schemes. Each of us lives in our own bubble... (my bubble is not iterm2 and not windows)
The problem with CLI colors is that they operate on the wrong abstraction layer. Individual program shouldn't send "this text is red" but "this text signals failure" and then terminal interprets "failure" as "red". Until this change happens (never) colors in CLI will remain a hot mess.
I really think we should converge to semantic codes. By example Background is zero, standard is 7, positive / negative, highlight, colored1,2,3 .. with correct defaults, and let the user have a common 8 or 16 colors palette in the terminal for all textmode apps. Imagine having some kind of unified color themes in the terminal.
I really wish you wouldn't. All the rinky dink colors and animations screw with the CLI output when you don't correctly detect whether the user's running the app interactively.
Keep it plain text. Regular, old, boring output is good.
I agree. So many TUIs from webshit devs don't even bother to call isatty, let alone check terminfo to see if ANSI escape codes are even valid for this terminal.
But modern open source subscribes to Mao's Continuous Revolution Theory. Calls for some measure of stability and sanity are usually dismissed with some form of the argument "awwww, is poor diddums afwaid of a widdle change?" Or in this case, "still using vi on your ADM3A, old timer? Our software is not for you."
I recently spent several evenings re-working all of my colours across all of my computers and screens; terminals, IDEs, etc. Ultimately, despite using the same tools, and always dark mode, across all of my machines, the setup for each was different.
I think it's safe to set a standard colour-set so that it's immediately usable, but beyond that, a user should be customising to their requirements.
Perception differs among people; many of the colours OP listed as unreadable, were barely an issue, bright yellow being the only one I could unequivocally agree on. Perhaps display type, configuration and colour calibration is an important factor, as well as individual perception, ambient conditions, brightness levels, contrast, and perhaps even more variables have a significant effect.
I've also learned, since adding an OLED Monitor to my desk alongside the IPS ones, that it's possible to have too much contrast; brightly coloured text alongside pixels that are literally off can be just as problematic to read at times, as low-contrast.
Interesting analysis, but perhaps it warrants a different conclusion: it's almost impossible to please everyone in this case. The resulting colours seem of some utility, but if you intend to make something more interesting you're probably annoy some (potentially large) group, in the case of legacy terminal coloring.
I used solarized since it came out but I dropped it some years back. I don’t think I can use it for dark mode. It’s too washed out and dull compared to light mode which is what I used to use it with. I just use whatever VS Code or VIM gives me as a dark mode and it’s usually better.
In addition to $TERM, I wish there was a standard variable defined by terminal emulators that would contain the background color. This would let programs choose their colors accordingly, rather than try for a one-size-fits-all.
Use 8 or 16 standard colors, let me configure them via terminal emulator or give me a way to completely change color scheme. That is it. Very rarely I need per-application colors in terminal (or anywhere really).
Black on white has seemed to work for centuries without issue. For general reading, throw in bold and italic and you're pretty much set. For programming, black on white is still a go to color (or lack thereof).
If the goal of the post is to pick terminal colors that contrast on both white/light and black/dark backgrounds, it means you're stuck with midtone colors (between light and dark). This is really limiting for color choice (there's no such thing as "dark yellow" for example), and lowers the maximum contrast you can have for text because you get the best contrast when one color is dark and the other is light.
Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
> Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
The responsibility for this lies with the color scheme not the terminal program.
That's called `\e[0;92m`, aka the ANSI terminal espace sequence for bright green. You have 15 others, that will be displayed however the terminal's user wants. They're already available in most terminal color libraries, too.
I use the built-in TokyoNight Day theme as my light theme in GhosTTY and I think it's almost perfect. Then I use TokyoNightMoon for dark. Works great. Hard to use anything else now.
If you're CLI application doesn't play nice with it (i haven't seen many) I don't use it.
Accommodating terminal colour schemes, however crazy to you they might be—white on black, black on white, dark brown on off-white Solarized-style, etc.—is basics of TUI design.
Personally I alternate between light on dark and dark on light (the latter sometimes together with OS-wide colour inversion feature).
> People who use white themed terminals are psychopaths anyway
Dark background is hell for anyone with astigmatism. It’s fine with 80x24 (vga text mode), but for anything higher feels like light needles on the retina. With astigmatism everything that is bright and small is duplicated, which means small characters is very difficult to read.
Can you work this into an AGENTS.md ? Just so happen to be working on multiple TUI at the moment: text-based modern web browser, VPS rental console, agentic coding wrapper.
layer8|1 month ago
When going beyond that, the colors really need to be configurable on the application.
JohnLeitch|1 month ago
That's the thing though, setting bg color opens up a lot of options, and constraining to invert is not sufficient in my opinion.
Arch-TK|1 month ago
I want to be able to switch existing terminals with existing applications between themes.
j4cobgarby|1 month ago
The CSS to make the terminals look like iTerm was smooth, to the point I read them as screenshots.
BeetleB|1 month ago
busterarm|1 month ago
8% of men of Northern European descent (and 0.4% of women) are red-green colorblind. That'd be a terrible choice. Use blue-orange, blue-red, or purple-green.
fassssst|1 month ago
red_admiral|1 month ago
tolciho|1 month ago
s_dev|1 month ago
https://michael.mior.ca/blog/coloured-ssh-terminals/
kiddico|1 month ago
red_admiral|1 month ago
account42|1 month ago
ori_b|1 month ago
https://no-color.org/
wredcoll|1 month ago
jammcq|1 month ago
bradrn|1 month ago
joshka|1 month ago
- colors are fairly natural
- 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
We use this for all the screenshots on https://ratatui.rs and https://github.com/ratatui/ratatui
It's available from the usual places https://iterm2colorschemes.com/, https://windowsterminalthemes.dev/?theme=Aardvark%20Blue, built in to ghostty, extension for vscode etc.
[1]: https://github.com/mbadolato/iTerm2-Color-Schemes/pull/417
tasuki|1 month ago
anal_reactor|1 month ago
makapuf|1 month ago
nateroling|1 month ago
I haven’t used dark mode anything for years. I set my monitor so it’s roughly as bright, or slightly brighter than, a piece of white paper.
No more flash-bangs when some website doesn’t support dark mode.
xenophonf|1 month ago
Keep it plain text. Regular, old, boring output is good.
skydhash|1 month ago
bitwize|1 month ago
But modern open source subscribes to Mao's Continuous Revolution Theory. Calls for some measure of stability and sanity are usually dismissed with some form of the argument "awwww, is poor diddums afwaid of a widdle change?" Or in this case, "still using vi on your ADM3A, old timer? Our software is not for you."
davidw|1 month ago
bl4kers|1 month ago
alias_neo|1 month ago
I think it's safe to set a standard colour-set so that it's immediately usable, but beyond that, a user should be customising to their requirements.
Perception differs among people; many of the colours OP listed as unreadable, were barely an issue, bright yellow being the only one I could unequivocally agree on. Perhaps display type, configuration and colour calibration is an important factor, as well as individual perception, ambient conditions, brightness levels, contrast, and perhaps even more variables have a significant effect.
I've also learned, since adding an OLED Monitor to my desk alongside the IPS ones, that it's possible to have too much contrast; brightly coloured text alongside pixels that are literally off can be just as problematic to read at times, as low-contrast.
jph|1 month ago
The source also has functions for nocolor, and detecting a dumb terminal setup that doesn't use colors, etc.
kps|1 month ago
wpm|1 month ago
godelski|1 month ago
And those print statements aren't going to work by default.
direwolf20|1 month ago
thinking_cactus|1 month ago
hnsmhthrow|1 month ago
loicd|1 month ago
0x457|1 month ago
assimpleaspossi|1 month ago
seanwilson|1 month ago
Ideally, instead of the CLI app switching to "bright green", it would pick a "bright contrasting green". So if the terminal background was dark, it would pick bright green, and for light background it would pick a darker green. There isn't CLI app implementations for this? This is similar to how you'd implement dark mode in a web app.
account42|1 month ago
The responsibility for this lies with the color scheme not the terminal program.
JoshTriplett|1 month ago
alt187|1 month ago
sroussey|1 month ago
Problem there is you can’t change css so at the moment the systems color preference changes thing will look bad.
Important considerations for custom formatters.
sroussey|1 month ago
https://github.com/workglow-dev/workglow/blob/main/docs/deve...
Play with it here using dev tools (you can ignore the website itself): https://workglow-web.netlify.app/
Docs including útil for checking dark mode: https://github.com/workglow-dev/workglow/tree/main/packages/...
bitwize|1 month ago
munificent|1 month ago
alfirous|1 month ago
unknown|1 month ago
[deleted]
pimlottc|1 month ago
otabdeveloper4|1 month ago
maximgeorge|1 month ago
[deleted]
lifetimerubyist|1 month ago
If you're CLI application doesn't play nice with it (i haven't seen many) I don't use it.
the_gipsy|1 month ago
[deleted]
taswellian|1 month ago
Arch-TK|1 month ago
If your software does something dumb when my theme switches to black on white during the day then I am just going to avoid using it...
strogonoff|1 month ago
Personally I alternate between light on dark and dark on light (the latter sometimes together with OS-wide colour inversion feature).
skydhash|1 month ago
Dark background is hell for anyone with astigmatism. It’s fine with 80x24 (vga text mode), but for anything higher feels like light needles on the retina. With astigmatism everything that is bright and small is duplicated, which means small characters is very difficult to read.
keepamovin|1 month ago
Colors, have been a perpetual nightmare.