3 ms·

I actually don't think it's that hard: Step 1: Most terminal emulators ship with a garbage default colour scheme. So change that. Personally I'm a fan of Sol

I actually don't think it's that hard: Step 1: Most terminal emulators ship with a garbage default colour scheme. So change that. Personally I'm a fan of Solarized (specifically dark, but I like their light theme too). However even if you don't like Solarized, there are plenty of other themes that are readable with any colour against the default backgrounds. Step 2: Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. This might be an unpopular opinion, but I actually consider that as user hostile. Reason being: I've already chosen a the best terminal colour scheme for my readability requirements (remember, this will differ for different people). Having a developer override that because they fancy themselves as a pseudo-designer is not helpful. By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default. As someone who spends most of their life in the terminal, following those two rules is enough to provide a consistent and easy terminal reading environment with almost-zero configuration overhead. I think the real problem is that we indulge developers using 8bit and 24bit colour escape codes.

weinzierl 2y ago
Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. How difficult is this in practice? (Julia's article mentions this idea too without going deeper into the struggles) A related topic is: Do terminal color schemes only concern themselves with the 16 base colors or do they also meddle with the RGB and greyscale parts. I mean you could also adapt the 8bit and 16bit colors to your readability requirements.
- hnlmorg 2y ago
  There is no 16bit. You cannot alter the 24bit (at least not on your average terminal emulator). Same is true for 8bit. Most terminal emulators tend not to support altering those colours either. In practice, the only application I use that I've had to configure the colours for was tmux. But I tend to forget about tmux because its one of those applications that needs a lot of a configuration from the outset anyway (in my opinion at least). There might be other "must have" tools that set the background colours too. I've either not needed them personally, or have completely forgotten about them
arp242 2y ago
> themes that are readable with any colour against the default backgrounds. Yes, but then there are applications that set both the text and background colour. For example pamix sets the background to black, or tmux's statusline, or ngrok. And you end up in a rabbit hole trying to deal with that.
- prmoustache 2y ago
  I don't know what pamix is but my rule of thumb is to use only apps that supports themes that are common in most terminals, text/code editor like solarized, gruvbox...
sim7c00 2y ago
Step2: do agree with the fact someone making a CLI tool should respect user preferences. it's also much easier just not to use the sequences in the tool so I don't get why people would do that in the first place :S. Step 1: I think here maybe the default setting should be solarized-dark/light on terminals. It's honestly a good and sane default. It's purpose built to be less hostile on the eyes in my opinion, which should likely be what's aimed for in a default setting... the themes and colors are there for people who like to stare at their terminal all day (if you only use it once or twice then you don't care about what color it has) so it should be eye-friendly defaults. if people want to muck about changing it to their own custom theme they won't be bothered about defaults anyway since they will immediately customize it. I personally hate the fact I even need to swap a theme, or download and reformat some Xresources file tediously (while looking at godawful colors in the process!). I just want my eyes not to burn.. don't care what colors yield that result.
- hnlmorg 2y ago
  I completely agree. And for what it's worth, I set Solarized dark as the default theme on the terminal emulator I've written. Though it's not quite ready to be used as anyone's primary TERM just yet.
- tmtvl 2y ago
  I would disagree that solarized is a good default, the colour it uses for blue (which is used by `ls' to show directories) is so low contrast it wears my eyes out.
  - kibwen 2y ago
    Seconded. By all means, people should use what they personally like, but solarized is really not designed to be a terminal mapping. Half the brights get mapped to totally different hues and the other half get mapped to indistinguishable shades of gray. Yes, the standard terminal color values are hideous, but we can do better than solarized.
    - hnlmorg 2y ago
bhaak 2y ago
> By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default. This touches on the problem of good defaults. If the user has to configure it then the user must know that it is configurable and then do it. This is a serious hurdle and only a tiny fraction of users will do it. Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors.
- hnlmorg 2y ago
  > Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. Agreed to an extent. I wouldn't call ignoring the systems colour preferences as "good defaults". But I do agree with your more general point. > 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors. Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Neither are standards either. It's a push to even call them a de facto standard because they're often not used by either terminal emulators nor application developer alike. There is another env var that does report user preferences: $COLORFGBG, but that receives even less support than the former two vars. There's also $NO_COLOR (or is $NOCOLOR?), which seems to be honored a little better. However the problem with this is it turns colour off completely. ie you cannot specify "use 4bit but not 8bit nor 24bit colour". Like all things terminal detection wise, it's all a big fat steaming mess of inconsistencies. Which is why I think the best default is 3/4bit or no colour at all if $NO_COLOR / not a TTY. And have all the cool 24bit themes as an optional extra.
  - bhaak 2y ago
    > Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Terminal compatibility that is expected to be used. If you only want the 16 base colors then this is the way to go. This is the most reliable and best supported way to get that in the terminal. If you want some tools to still output 256 colors, you can change the TERM variable on the fly: "TERM=$TERM-256color infocmp -L". You also should unset COLORTERM. It's for specifying that this terminal supports 24bit colors.
phkahler 2y ago
>> Step 2: >> Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. I was going to point out that the author never takes a step back and asks "What would be the best way to handle this?" The problem there is we have to define what "best" is. IMHO that involves a number of principles. My preferences are: 1) Any user customization should be in one place. 2) The impact on programs should be minimal (in LoC for example). Both of those suggest the solution belongs in the terminal. IMHO it starts with terminal programs having sane default colors. What that means is fuzzy, but so is this whole discussion. IMHO colors should follow the "standard" so that blue is still recognizably blue. But consideration should be given to the common forms of color blindness - for example I have a hard time reading pure red on black (adding a bit of anything helps this, don't just use ff0000). Once terminals get fixed to have sane defaults, CLI programs should use those 16 standard colors. Any attempt to use 24bit here is either saying "I give up on getting those terminal folks to offer sanity" or it's saying something like "I know best", but either way users end up with N programs they have to configure. Lets not define themes in cli apps OK? Remember, this is my answer to "what would be the best way to handle this?" I have similar thoughts when it comes to web sites and fonts. Present content in HTML so users can configure how they want to see it. Similar for page formatting - it's not a magazine layout, let it flow. Also stuff in desktop software. IMHO Wayland compositors should remember window placement. It was stupid for every X program to store and restore its window position. Wayland says knowing about the environment is a security issue (and I agree) but then it becomes the DEs job to handle this memory. It also unburdens ALL the apps from having code for this. There are other areas where that question comes up "Where in the software stack should this thing be handled?" Whatever your opinion, I believe you should start by answering the questions around that word "should". What are the goals in selecting where a thing gets handled? My answers always lean toward simplicity and maintainability. What other principles might I adopt to answer these questions?
- kevin_thibedeau 2y ago
  > What would be the best way to handle this? A styling service from systemd.
fwip 2y ago
Solarized Dark, specifically, is not well-suited for terminal use, because the author has assigned "bright black" to nearly the same color as the background. Many applications expect that 'bright black' text will be visible against the background. See here for many examples: https://github.com/altercation/solarized/issues/220 https://github.com/altercation/solarized/issues/220 Nearly all other colorschemes represent 'bright black' as a gray color, which is readable against the black background.

weinzierl 2y ago

Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. How difficult is this in practice? (Julia's article mentions this idea too without going deeper into the struggles) A related topic is: Do terminal color schemes only concern themselves with the 16 base colors or do they also meddle with the RGB and greyscale parts. I mean you could also adapt the 8bit and 16bit colors to your readability requirements.

hnlmorg 2y ago
There is no 16bit. You cannot alter the 24bit (at least not on your average terminal emulator). Same is true for 8bit. Most terminal emulators tend not to support altering those colours either. In practice, the only application I use that I've had to configure the colours for was tmux. But I tend to forget about tmux because its one of those applications that needs a lot of a configuration from the outset anyway (in my opinion at least). There might be other "must have" tools that set the background colours too. I've either not needed them personally, or have completely forgotten about them

arp242 2y ago

> themes that are readable with any colour against the default backgrounds. Yes, but then there are applications that set both the text and background colour. For example pamix sets the background to black, or tmux's statusline, or ngrok. And you end up in a rabbit hole trying to deal with that.

prmoustache 2y ago
I don't know what pamix is but my rule of thumb is to use only apps that supports themes that are common in most terminals, text/code editor like solarized, gruvbox...

sim7c00 2y ago

Step2: do agree with the fact someone making a CLI tool should respect user preferences. it's also much easier just not to use the sequences in the tool so I don't get why people would do that in the first place :S. Step 1: I think here maybe the default setting should be solarized-dark/light on terminals. It's honestly a good and sane default. It's purpose built to be less hostile on the eyes in my opinion, which should likely be what's aimed for in a default setting... the themes and colors are there for people who like to stare at their terminal all day (if you only use it once or twice then you don't care about what color it has) so it should be eye-friendly defaults. if people want to muck about changing it to their own custom theme they won't be bothered about defaults anyway since they will immediately customize it. I personally hate the fact I even need to swap a theme, or download and reformat some Xresources file tediously (while looking at godawful colors in the process!). I just want my eyes not to burn.. don't care what colors yield that result.

hnlmorg 2y ago
I completely agree. And for what it's worth, I set Solarized dark as the default theme on the terminal emulator I've written. Though it's not quite ready to be used as anyone's primary TERM just yet.
tmtvl 2y ago
I would disagree that solarized is a good default, the colour it uses for blue (which is used by `ls' to show directories) is so low contrast it wears my eyes out.
- kibwen 2y ago
  Seconded. By all means, people should use what they personally like, but solarized is really not designed to be a terminal mapping. Half the brights get mapped to totally different hues and the other half get mapped to indistinguishable shades of gray. Yes, the standard terminal color values are hideous, but we can do better than solarized.
  - hnlmorg 2y ago

bhaak 2y ago

> By all means, they can have an option to enable themes in their tool if they wish, but that should be opt-in, not the default. This touches on the problem of good defaults. If the user has to configure it then the user must know that it is configurable and then do it. This is a serious hurdle and only a tiny fraction of users will do it. Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors.

hnlmorg 2y ago
> Over the years I've come to the conclusion that you must throw your new features into the face and shove good defaults down the throats of users, otherwise these feature are hardly used. Agreed to an extent. I wouldn't call ignoring the systems colour preferences as "good defaults". But I do agree with your more general point. > 8bit and 24bit colors are already opt-in and you can configure it. Your TERM and COLORTERM environmental variables determine if a (well behaved) terminal program will use those colors. Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Neither are standards either. It's a push to even call them a de facto standard because they're often not used by either terminal emulators nor application developer alike. There is another env var that does report user preferences: $COLORFGBG, but that receives even less support than the former two vars. There's also $NO_COLOR (or is $NOCOLOR?), which seems to be honored a little better. However the problem with this is it turns colour off completely. ie you cannot specify "use 4bit but not 8bit nor 24bit colour". Like all things terminal detection wise, it's all a big fat steaming mess of inconsistencies. Which is why I think the best default is 3/4bit or no colour at all if $NO_COLOR / not a TTY. And have all the cool 24bit themes as an optional extra.
- bhaak 2y ago
  > Unfortunately it's not that simple. Both the "256color" suffix to $TERM and $COLORTERM env vars report terminal compatibility -- not user preference. Terminal compatibility that is expected to be used. If you only want the 16 base colors then this is the way to go. This is the most reliable and best supported way to get that in the terminal. If you want some tools to still output 256 colors, you can change the TERM variable on the fly: "TERM=$TERM-256color infocmp -L". You also should unset COLORTERM. It's for specifying that this terminal supports 24bit colors.

phkahler 2y ago

>> Step 2: >> Avoid any CLI tool that uses escape sequences for 8bit or 24bit colours by default. I was going to point out that the author never takes a step back and asks "What would be the best way to handle this?" The problem there is we have to define what "best" is. IMHO that involves a number of principles. My preferences are: 1) Any user customization should be in one place. 2) The impact on programs should be minimal (in LoC for example). Both of those suggest the solution belongs in the terminal. IMHO it starts with terminal programs having sane default colors. What that means is fuzzy, but so is this whole discussion. IMHO colors should follow the "standard" so that blue is still recognizably blue. But consideration should be given to the common forms of color blindness - for example I have a hard time reading pure red on black (adding a bit of anything helps this, don't just use ff0000). Once terminals get fixed to have sane defaults, CLI programs should use those 16 standard colors. Any attempt to use 24bit here is either saying "I give up on getting those terminal folks to offer sanity" or it's saying something like "I know best", but either way users end up with N programs they have to configure. Lets not define themes in cli apps OK? Remember, this is my answer to "what would be the best way to handle this?" I have similar thoughts when it comes to web sites and fonts. Present content in HTML so users can configure how they want to see it. Similar for page formatting - it's not a magazine layout, let it flow. Also stuff in desktop software. IMHO Wayland compositors should remember window placement. It was stupid for every X program to store and restore its window position. Wayland says knowing about the environment is a security issue (and I agree) but then it becomes the DEs job to handle this memory. It also unburdens ALL the apps from having code for this. There are other areas where that question comes up "Where in the software stack should this thing be handled?" Whatever your opinion, I believe you should start by answering the questions around that word "should". What are the goals in selecting where a thing gets handled? My answers always lean toward simplicity and maintainability. What other principles might I adopt to answer these questions?

kevin_thibedeau 2y ago
> What would be the best way to handle this? A styling service from systemd.

fwip 2y ago

Solarized Dark, specifically, is not well-suited for terminal use, because the author has assigned "bright black" to nearly the same color as the background. Many applications expect that 'bright black' text will be visible against the background. See here for many examples: https://github.com/altercation/solarized/issues/220 https://github.com/altercation/solarized/issues/220 Nearly all other colorschemes represent 'bright black' as a gray color, which is readable against the black background.