When going beyond that, the colors really need to be configurable on the application.
That's the thing though, setting bg color opens up a lot of options, and constraining to invert is not sufficient in my opinion.
For example like Mutt does: http://www.mutt.org/doc/manual/#color
Eh. Doing green/red text color with default background, maybe inverted works amazing for me. In fact, I'd say that every sensible colour scheme for a terminal should have as the default foreground/background colours something that is more or less contrasting against every other explicitly named colour, including black and white (I personally have #212121 on #EEEEEE).
I want to be able to switch existing terminals with existing applications between themes.
The CSS to make the terminals look like iTerm was smooth, to the point I read them as screenshots.
Not differently for each program's output.
Sure, if it was a status indicator and I used red for "good", I can see the point. But over the last few years I've had too many people tell me "Don't use red, people will think something is wrong" for things not semantically tied to good/bad.
People wear red clothes. They buy red cars. They eat red food. They date red heads. Red is OK.
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.
I'd like to recommend rofimoji. I have it bound to a hotkey, so whenever I want to type an emoji, I just hit that hotkey and then a window pops up with my most recent emoji already visible at the top. Then I start typing in words that describe the emoji that I want like "crying" and it filters the list. Finally I select one and it pastes it into whatever text box I had selected before I hit the hotkey. My only complaint is I wish it worked for all unicode codepoints instead of just the emoji.
Globe key + E on Mac, Windows key + period on Windows, Ctrl + period on GNOME, Super key + period on KDE, yada yada.
- 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
"Terminal, Konsole, PuTTY, Xresources, XRDB, Remmina, Termite, XFCE, Tilda, FreeBSD VT, Terminator, Kitty, MobaXterm, LXTerminal, Microsoft's Windows Terminal, Visual Studio, Alacritty, Ghostty, and many more."
You may have used data from it without knowing about it.
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.
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.
export STDOUT_COLOR_START='[34m'
export STDOUT_COLOR_STOP='[0m'
export STDERR_COLOR_START='[31m'
export STDERR_COLOR_STOP='[0m'
print_stdout() {
printf %s%s%s\\n "${STDOUT_COLOR_START:-}" "$*" "${STDOUT_COLOR_STOP:-}"
}
print_stderr() {
>&2 printf %s%s%s\\n "${STDERR_COLOR_START:-}" "$*" "${STDERR_COLOR_STOP:-}"
}
The source also has functions for nocolor, and detecting a dumb terminal setup that doesn't use colors, etc.
tty -s
export STDOUT_COLOR_START="`tput setaf 4`". declare STDOUT_COLOR='\e[34m'
declare STDERR_COLOR='\e[31m'
declare COLOR_STOP='\e[0m'
print_stdout() {
echo -e "${STDOUT_COLOR}${*}${COLOR_STOP}" &> /dev/stdout
}
print_stderrr() {
echo -e "${STDERR_COLOR}${*}${COLOR_STOP}" &> /dev/stderr
}
And those print statements aren't going to work by default.
print_color () {
print -P "%F{$1}$2%f"
}
print_color "green" "This is printed in green" declare GRN='\e[1;32m'
declare RED='\e[1;31m'
declare YLW='\e[1;33m'
declare CYN='\e[1;36m'
write_log() {
echo -e "[$( date +'%c' )] : ${1}\e[0m" | tee -a ${logfile}
}
write_log "${RED}I'm an ERROR"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.
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.
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/...
Keep it plain text. Regular, old, boring output is good.
Most of its successors are more like "shitty xterm emulators" whose conformance tests are "do my favorite mOdErN CLI apps work".
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."
If you're CLI application doesn't play nice with it (i haven't seen many) I don't use it.
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...
Personally I alternate between light on dark and dark on light (the latter sometimes together with OS-wide colour inversion feature).
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.
Colors, have been a perpetual nightmare.
