For any new programs I make that involve terminal, I'm going to make them respect NO_COLOR as it seems pretty trivial.
> "If your software outputs color by default, please consider not doing so."
I'd love to hear good reasoning why using color by default is bad. I can think of some arguments for doing so but the website is not elaborating. E.g. default color choices assume dark terminal or they are not modifiable or developers in general tend to do a bad job at it or something along those lines etc.
I think color can make reading faster and easier, it's why syntax highlighting exists.
Unless you’re using the 24bit color extensions, the default color choices are pretty abstract: if they are readable in one color scheme and unreadable in another, the problem is in the color scheme’s selection of colors.
In my experience most default terminal colorschemes are rather poor. You can't even make the seemingly obvious assumption that light colors have good contrast against "black" and that dark colors have good contrast against "white".
> the problem is in the color scheme’s selection of colors.
Application can also set the background colours. If I "fix" things so that it will work well on a light background then it will be broken on applications that explicitly set a dark background.
For most cases this could probably be fixed by using a more abstract color scheme: rather than "red", "blue", "grey", and such, maybe "warn_0", "emphasis_0", "dull_0", etc.
Is there a good use case for applications explicitly setting a dark background? If you're playing games in your terminal I can see it, but I'm having a hard time imagining a good use case beyond that.
I don't particularly hate colour, but I do find it annoying sometimes. I don't like my prompt to be overly loud but it has some colour to make it stick out. When programs output colour it makes it a bit harder to find where I typed the command. Again, though, this isn't the biggest of pain-points for me.
When most everything is b/w a splotch of color is very eye catching - but when your terminal always looks like a technicolor yawn a red error flashing by will be unnoticed.
> I think color can make reading faster and easier, it's why syntax highlighting exists.
Except you don't know the colour scheme of the terminal: is it a form of black text on white background, or white/green text on black background? If you decide to output something as (dark) blue text, how legible will it be?
As someone who has a black background, comments shown as dark blue make for difficult reading of many config files with Vim†.
† And another thing: when I invoke "vi" I want Vi: I do not want Vim. If I wanted Vim I would have typed in "vim". Having "vi" call Vim is a major pet peeve of mine: have to change that silly default in most distros nowadays.
This is why I think that every terminal color scheme should just have the right contrast for all colors with the default background. There are 16 colors and these days terminals are pretty much exclusively used for text, so why does your color scheme have a color that is illegible on the default background?
I understand that all bets are off if the application starts mixing and matching background colors, but there's no reason why your dark blue can't just be a little lighter.
(To be clear, I'm not blaming you for this, a lot of built-in color schemes have problems like this.)
Okay, well, true color mode is definitely a problem. But that's so obviously disrespectful that I don't think that you're going to get people who are using that on board with this new standard.
This is true, and it is also a fact exclusive to dark blue on black, solvable by not using dark blue ever. For any other color, it is easy unless it is the same color as the background.
In contrast, there are plenty of people that push this as a handy default. It's all over the place and sneaks in via all sorts of routes -- very unfortunately for those people who want vi to invoke something that is closer to genuine Joy vi than VIM and NeoVIM are, even in their "compatible" modes.
I think color can make reading faster and easier, it's why syntax highlighting exists.
Not everyone likes or wants syntax highlighting. Personally I find it distracting at best and often actively hostile to being able to read the code (dark blue on black for comments!?)
Doesn't this just mean you're using a suboptimal syntax theme? There a million out there with sufficient color contrast, there's no reason not to use one.
> I'd love to hear good reasoning why using color by default is bad.
About 1 in 12 men and about 1 in 200 women have some kind of color vision deficiency. Most commonly they have difficulty distinguishing green and red*. The default color choices essentially never account for this.
* Yes this does mean traffic lights are a problem. Fortunately for Americans, the red light is either far left or on top.
If a color blind person can't distinguish between a green letter and a red letter, how does disabling color so both the green letter and the red letter are white help? If it mattered that you weren't able to distinguish between them, now nobody can. If it didn't, then the point's moot.
Precisely. This is only an issue if the _only_ difference between an error and success message is the colour.
As long as the information is communicated other ways as well, the colour is just a helpful thing for discriminating the messages and the loss of it by someone that’s colour blind, using a terminal with a configuration that doesn’t allow colour, or even just is sitting somewhere the sun is shining on their monitor and making colours hard to differentiate is… inconsequential.
> This is only an issue if the _only_ difference between an error and success message is the colour.
Except that a color bind person doesn't see monochrome, they see color, but perceive it differently. So the color palette problem isn't confined to only red and green, but also to other colors, because the spectrum as a whole is distinguished differently. Also, red/green color deficiency, while the most common, isn't the only kind of color blindness.
Terminals fortunately make it quite easy to map the basic 8 colors to whatever you like. There are very few people who can’t select 8 mutually distinguishable colours. They could even choose shades of grey!
This is an argument against using 256-color or true color though.
No it isn't. The 256 colour system is based upon a palette, too. Indeed, in almost all terminal emulators it is the same palette as the AIXTerm 16 colour system, which just uses its first 16 entries. (They could be theoretically two different palettes. I know of no terminal emulator author who has implemented it this way. I thought of doing so, but even I didn't.)
> I'd love to hear good reasoning why using color by default is bad.
Your color choices might not align with the user's color scheme. Might be necessary to further process the output which means someone has to strip out the escape codes.
Unfortunately, the idea that one can set "solarized" colours, where the palette for the 16 AIXTerm colours is nothing like the AIXTerm colour set, has long since taken root in many people's minds, including, ironically, the minds of people who use this to turn off colourization by setting the AIXTerm 16 colour palette to various shades of grey.
I am in agreement that colors by default, if used judiciously, are good. Disabling them by default seems like minority appeasement. If there are people who don't like colors, they should arrange for their own configurations to their terminal globally rather than have everyone else bend to their will.
Secondly, we don't need to respect this new flag for no color because most programs already disable their color output if they detect absence of a real tty by isatty(). So people who want to enforce no colors for all programs should either find a hack to put the running program under illusion, or just pipe output throught cat which will do it anyways. There is no point in having more unnecessary standards that will never realistically be complied with.
As has been mentioned multiple times in the thread, color schemes are highly configurable. It doesn't seem like it would be very hard to put together 16 colors that are easily distinguishable by the colorblind.
Color can definitely aid in understanding when it’s used with consistency. When it’s inconsistent, it becomes an impediment to understanding. The terminal is a place where you have lots of different small tools that you are using in conjunction. Even if each author uses color with consistency in their tool, the full collection of tools will be inconsistent with one another.
A hypothetical example: imagine syntax highlighting where strings are green, function names are blue, and comments are gray when you’re inside a function definition… but strings are green, function names are red, and comments are gray when you’re inside a lambda/closure/anonymous function definition… but strings are gray, function names are red, and comments are a syntax error when you’re in a string interpolation expression. In the terminal, each of those different contexts is likely to be a different tool. The author of the lambda highlighter arguably made a non-standard choice but they close PRs about this issue with “wontfix” because it invites too much bikeshedding. The author of the “string interpolation” tool wanted their tool to differentiate between the template/parent string and a string that happens to be part of the expression being interpolated. The string interpolation tool’s author has a good reason for their choice and their tool is very consistent about it, it even has a black magick regex incantation that gets arbitrarily nested cases correct. Each author has a good point and they’re all internally consistent, but when you are plugging them all together into a general purpose highlighter it still ends up inconsistent for you.
Or a real-world example: at the machining workshop, we have a painting cabinet filled with spray cans and paint tins of different bases. We don’t paint our products - that cabinet exists because whenever a new set of tools is brought to the shop, we paint all the flathead screwdriver handles yellow, all the Phillips-head screwdriver handles red, the Allen keys get a red band if they’re Imperial, a blue band if they’re metric, the wrenches likewise get red for Imperial, blue for metric, and so on. The standardized colors make it much easier to grab the right tool quickly, but we can’t rely on tool manufacturers to all globally standardize on colors since some of them have other constraints that we don’t care about (if they manufacture insulated screwdrivers for electricians as well, they will often reserve both yellow and red because “yellow and red two-tone” is the color scheme for insulated screwdrivers, so their non-insulated screwdrivers will be green for flathead, blue for Phillips - or purple for flathead, green for Phillips - etc). The terminal is an even more extreme example since it’s rare to get a whole set of terminal utilities from the same author, so all your number 2 Phillips would be from a different manufacturer than your number 1 Phillips. Also the terminal is sort of like a workshop where all the tools, even the screwdrivers, can be machine-mounted so maybe you want no paint on the handles because otherwise it rubs off on the chuck and the build-up messes up your tolerances over time, or something.
> "If your software outputs color by default, please consider not doing so."
I'd love to hear good reasoning why using color by default is bad. I can think of some arguments for doing so but the website is not elaborating. E.g. default color choices assume dark terminal or they are not modifiable or developers in general tend to do a bad job at it or something along those lines etc.
I think color can make reading faster and easier, it's why syntax highlighting exists.