No_color
no-color.org
no-color.org
Quite opinionated for not giving additional 𝘃𝗮𝗹𝗶𝗱 arguments.
Also the arguments regarding colorblind crowd being unable to distinguish colors are weak, as accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means, so that everybody has their chance to understand it (e.g. setting links in a distinguished color and underlined).
Using colors (e.g. rkhunter malware report with its hundreds of checks uses green for success and red for warnings/errors) is not only enjoyed by many, but a relieve for ADDeez.
Whoever doesn't want to have color, just pipe anything through ansi2txt; https://askubuntu.com/questions/984357/how-do-i-pipe-each-co...
Especially since accessibility in terminal environments simply isn't a thing. The terminal is a grid of cells that contain individual characters. Screen readers and other accessibility tools cannot know whether those characters constitute runs of text or separators, they cannot know which texts belong together, what their semantic relation is, etc. etc.
If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable. Proper accessibility requires semantic labeling of visual output, and the terminal display protocol doesn't provide that capability. Hand-wringing about a specific aspect like color blindness only serves to avoid discussing the elephant in the room, which is that TUI programs are fundamentally not accessible.
They're not irreconcilable because accessibility is not binary. Not every user benefitting from accessibility features is blind. Sometimes people without any disability prefer e.g. high-contrast modes, some people just dislike rapidly flashing lights even if they don't get seizures from it, some may just see no benefit in terminal coloring except in some rare cases.
Many terminal programs already support various color output options, additionally checking an environment variable isn't a big deal and doesn't affect anyone not using it.
I'm always curious what someone means when they say that something "is not binary". The phrase seems to imply that the situation is more complicated than it appears at a glance, but I've noticed a pattern in which the people who claim things to be "non-binary" habitually dismiss valid prose before actually engaging with them. They don't tend to actually explain themselves, they simply spout unverified information as if it is truth.
In this case, a program isn't "accessible" or "not accessible" but rather degrees of accessibility. Not everyone is 100% blind, so small accessibility features makes it easier for them while not being accessible to 100% of the population.
I am aware. My issue is with people using the phrase as if the folks they are arguing with aren't aware that the world isn't black and white, but actually a complicated place in which nuance and forethought are the norm.
> If accessibility is something you care about, don't write TUI programs. The two concepts are irreconcilable.
Which seems to indicate they see accessibility as something that is black or white, either you're accessible and don't write TUI programs, or you go ahead and write TUI programs and forget any sort of accessibility.
While the reality is that even if you write TUI programs, you can make them more accessible by following paradigms like "don't just use colors as visual indicators".
"irreconcilable" basically implies that there is a binary choice -- either use a TUI or aim for accessibility, but you can't have both. The responder was saying that actually it's not a binary choice -- there are degrees of accessibility, and some accessibility can be attained within a TUI.
Disagreeing with someone, using valid arguments, is not the same as squelching discourse.
I can relate with your position; I understand what you're saying. I guess my point is that some words that humans speak can strike a nerve in others. For instance, apparently I'm a huge Temple Grandin fan. I didn't know that until I mentioned the name Temple Grandin to my girlfriend of nearly five years recently and she basically snapped and told me that she never wanted me to say that name again. Apparently when I first met her I had a lot of good things to say about Temple Grandin, and I guess throughout the following five years I've mentioned Temple Grandin enough that it just raises her hackles when she hears it now. She's a good person, and absolutely does not have anything against Temple Grandin. She just doesn't like hearing that name when it's my voice speaking it.
I'm not sure if you had this in mind when you said "non-binary", but I also think along the same lines you just noted, that there is a difference between "not binary", and "non-binary". The latter could evoke connotations to the culture wars and gender identity -- though that of course has nothing to do with accessibility (of TUIs, bathrooms might be another matter).
Then again, I'm neither American nor a native English speaker, so I hardly have much authority on this point.
It's important to remember that during that time, many words were misappropriated (edit) by both sides in order to fit an agenda. Before that period of upheaval, the phrases that were misappropriated were not generally offensive, even to the people who found them confusing. Up until that point I truly believe that most people regarded such unrelatable concepts (i.e. a person identifying as something other than their physical makeup would suggest) as being simply unrelatable, but tolerable. I don't think most people had strong feelings one way or the other before the upheaval. I think when I hear those "dirty" words now though, that I experience some form of PTSD. The people with the megaphone (again, on all sides) did a damn fine job dividing all of us, imo.
If I write for myself and package/publish for others, the user has a choice not to use my program.
There's a whole world of options between "tiny fonts on a high resolution screen" and "screen reader" but things like large fonts, legibility-focused typefaces, zoomable applications and high contrast don't seem to be a priority (looking at you, MacOS).
This is all a big part of why I work primarily in a terminal emulator. I can control all of these things.
In the default state (not on the “alternate screen” and with wrapping enabled; i.e. in ls not vim) terminal emulators do record which runs of text belong together and which don’t, in order to be able to rewrap lines if the user resizes the window. (This is as universal as it is unspecified. Which is a shame, because it’s highly non-obvious how this should interact with e.g. programmatic cursor movement.) I know nothing about the accessibility story, but the “grid of cells” picture is simply untrue.
And yes, you need to patch your screenreader to ignore CSI color sequences because many programs are not well-behaving and outputting them even when terminfo doesn't specify them as supported.
And yes, you cannot use all TUI programs (like vi for example), but you can reliably disable these programs by using a terminfo with the hardcopy flag set.
Why is this on me and not the developer of the screenreader application?
> accessibility best practices suggest to convey semantically relevant markup and content in multiple sensory means
Yeah, we might not agree on that. That practice might be a tad overrated or overused. In some contexts it might make sense, but that doesn't mean any semantic difference should be expressed. E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names? Why not color by file size? Or by age? How am I going to remember those colors? Plus, it's unusable in a script, because then "ls" suppresses the color.
But why argue (pretty harshly) against a proposal that won't affect the way you see the output? And why give such a weird, unfriendly option to remove color?
You can change the specific colors used by your terminal emulator, at least for the basic 16 colors.
> E.g., why should "ls" assign different file types different colors? Did I ask for it? Are they not all file names?
I agree that coloring .tgz is useless. But it is useful to be able to tell directories, executables, symlinks apart (I also use the -F flag to have a textual indicator).
> Did I ask for it?
Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Why is the default wallpaper of Windows 11 a blue flower-ish thing? Did I ask for it?
Software has defaults, and then Linux distros may add their customizations on top. Are those defaults the universal best way to do things? No. But usually, you can just customize them to your liking.
Doesn't that contradict the "semantic marking" argument? Now you can't predict what the output will look like, and someone might like the color of grep output, but not ls.
I simply alias most commands that output color, BTW. The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
The only disadvantage of NO_COLOR is that you can't unset it at the start of the command line. At least, I wouldn't know how. NO_COLOR=true/false could be switched per command.
> Why should `ls` show files in alphabetical order? Wouldn’t the last-use order be more helpful?
Apart from the fact that looking for a name becomes harder (and you clearly don't know what you're looking for if you only use ls), that ls -1tr is your friend, and that there always is some order, last-use order doesn't make sense for other cmd line utilities. There's no point in a global "SORT_ORDER=last-use" environment variable.
env -u NO_COLOR command...
There is no need. An empty string is equivalent according to the spec, so:
NO_COLOR= command
> The GNU utils all seem to support --no-color, and that's reasonable too, and flexible, except aliasing can be a bit tricky, and you have to add it for multiple commands, and scripts often don't recognize it.
I have more luck with setting the environment variables, e.g.
LS_COLORS="rs=0:di=0:ln=0:mh=0:pi=0:so=0:do=0:bd=0:cd=0:or=0:mi=0:su=0:sg=0:ca=0:tw=0:ow=0:st=0:ex=0:*=0:"
GREP_COLORS=ms=0:mc=0:sl=:cx=:fn=0:ln=0:bn=0:se=0> plus, it's unusable in a script, because then "ls" suppresses the color.
ls doesn't do anything different in a script, you probably just have an ls alias. Aliased are typically not sourced for non interactive shells
example alias:
$ alias ls
ls='ls --color=tty'
("tty" and "if-tty" are the same as "auto")
alias ls='ls -F'It's not color blindness, it's lack of basic testing in real-world conditions where not everyone can use dark-themed terminals.
The default colors in Debian's 'ls' output, or 'ncdu', blend perfectly with a light background theme, so the net result is a loss of information for the user.
(I believe neovim uses the DCS 11 inquiry to determine the actual background colour on xterm-compatibles. I believe vim currently does not, relying on environment variables only. I may be stale or otherwise mistaken on both.)
If anything, the correct version of this statement would be "Vim was created when light backgrounds were a fad".
The "natural" background of the terminal is dark, including ADM-3A (terminal "responsible" of vi's HJKL).
Accordingly, the Xerox Alto had a light background too, back in the 1970s. Demonstrated here with Smalltalk:
And here with a GUI based text editor:
What little actual research exists suggests dark on light is more readable for people with normal vision. People with cataracts benefit from light on dark, and people with astigmatism benefit from dark on light.
Modern screens are more or less unique in not limiting background colors so we can use any and and argue which one is better.
You may have missed that this is about CLI applications, not web-pages.
But CLI apps don’t have markup, much less semantic markup.
That was my point.
No. Accessibility is about awareness. We use ramps, rails, elevators, and other tools to make a 3D world accessible to people who rely on wheels.
Similarly, here is the one thing you need to know to use color accessibly: think in HSB (or HSL or HSV), and always vary at least two of those dimensions.
I am fine if you want to use red/green for status as long as it is light red and dark green (or vice versa).
Encoding information redundantly in two dimensions makes the result accessible to those who can’t see some/all difference in one of those dimensions.
There. Now you can enjoy your damn purple skies and green fire trucks without worrying about me.
Why? What specific benefit does that convey to my users? When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
There is exactly one use case for this, and that's programmatically processing output in a pipline. And that one is a solved problem, as good libraries for colored output usually check isatty()
And before anyone says "colorblindness": I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
Readability, reduced visual noise, and compatibility with any terminal color scheme.
> When I decided to color the output, I did so for a reason, otherwise I wouldn't have gone through the trouble of doing so.
Was your reason something other than preference? If not, did you consider that others may have different preferences?
Semantically colored text, by definition, reduces visual noise. After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
You may like color, that's fine. But for me, the effect of colored text as it is used today is akin to prose with every other word randomly colored[1], often in a color that blends in with the background of the page.
Turning off the colors, for me, is a large improvement. Using them sparingly, carefully, with a preference for bolding and italicizing to make metadata stand out from data, would be better. This is far harder to patch in to most programs, and a much larger uphill battle. Turning off colors is, by and large, the low hanging fruit.
[1] https://cdn.gbraad.nl/images/blog/english-text-highlighting....
Not by definition. It adds information. If that matches the text 100%, it is redundant. If it isn't, it adds noise. So it depends very much of what you consider "noise".
> After doing a bit of googling there are infact a number of studies that show that colored text seems to positively affect both short term free and serial recall.
I'm curious what you think are good sources for that. Many studies have been done on color and text, but I've never seen one that gives a good argument in favor of coloring command line output.
Note: recall isn't a goal of color in (most) command line output. Perhaps there is some case, but I wouldn't know which one.
Information is only noise if it isn't the signal you are after. Also if the text contains some information that doesn't mean color can't make it easier to distinguish.
This is the truth about every decision one makes, even if the reason is trivial, fleeting, or barely overruled some opposing reasoning, which shouldn't mean that no one can suggest anything to you. This is someone trying to affect your future decisionmaking, not to take the decision from you.
> I think if someone is colorblind, they are likely to have set up their terminal in a way that deals with colored output already.
Maybe they're not on their home machine or terminal?
Using a global standard for color configuration would be nice, though. I often want coloured output and am left with all kinds of command line flags or environment variables just to get tools to output text normally.
I guess the terminal should not start putting hands into this game since stdout is generally assumed to be binary (not even text).
The author has a use case (I believe their issue is that unlike $NO_COLOR, setting $TERM takes precedence over any configs or --color flags), though to me it seems like a rather niche problem. Anyways, if you support $TERM, it's easy to support $NO_COLOR as well, so there's not much of a reason to not follow the standard.
Lots of software out there, especially from nodebros, blithely ignores $TERM and just barfs ANSI escape codes to standard out, under the rubric that, well, everybody uses macOS Terminal/iTerm/Alacritty.
Because although the meanings aren't specified the TERM environment variable itself is named in the Single Unix Specification, unlike some other environment variables (even COLORTERM).
And the TERM=dumb convention is documented widely and long, at least as far back as 1983, in books and in on-line doco.
* It's in the McGraw-Hill book _Introducing the UNIX System_published in 1983. Amusingly, this uses the C shell setenv syntax to demonstrate setting it, indicating how the C shell was the Bourne Again shell of its time.
* It's in the 4BSD manual page for TERM(7) from 1985. It's still in the OpenBSD manual page for term(7) to this day: https://man.openbsd.org/term.7 . The 4BSD TERM(7) manual had a list of well-known types, and "dumb \ \ \ \ \ \ \ \ terminals with no special features" was one of them. See https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/man/... for example.
* It is the documented default fallback for AT&T Unix System 5 Release 4's tset(1) command when nothing in the the ttytype(5) file matches. "If the serial port is not found in /etc/ttytype, the terminal type is set to dumb." said the USL manual.
(No, it's not the ncurses tset(1)'s fallback. Bear in mind that the "n" in "ncurses" meant "new". ncurses was a reimplementation. Like many reimplementations, it missed bits of actual System 5 Release 4.)
* Setting TERM to the right thing instead of a dumb terminal type in order to enable colour is in Coffin's _UNIX System V Release 4 Complete Reference_ published in 1991.
This is how long and wide a pedigree TERM=dumb has.
Even I, who is progressive enough that I have joined the bright new future of 1976, with my softwares defaulting to TERM=ansi if it isn't set, document the convention that TERM=dumb meant using no escape or control sequences and just (a few) C0 control codes such as LF and CR. See https://jdebp.uk/Softwares/nosh/guide/commands/TERM.xml and https://github.com/jdebp/nosh/blob/79b1c0aab9834a09a59e15d47... . And yes, I implement that convention. "dumb" gets several mentions at https://jdebp.uk/Softwares/nosh/guide/commands/TerminalCapab... .
Almost all software that outputs colors only checks if the output is a TTY and doesn't look at the TERM variable.
This is a wide range of softwares from the %F and %B sequences in the Z shell's prompt through Midnight Commander to the clang++ compiler.
You've clearly either never looked at much doco or have a truly terrible memory. In addition to all of the books and whatnot over a span of 40 years, even The Linux Documentation Project got in on the act: https://tldp.org/HOWTO/Text-Terminal-HOWTO-8.html#early_term...
And StackOverflow: https://stackoverflow.com/a/39005551/340790
Most programs that output color already disable color if the output isn't a terminal; in fact I just pipe the output to cat when I want color off.
This page seems to purely be about interactive use with no color.
I only ever had to do it once (using LD_PRELOAD) because there was an insane vendor binary blob that would return "SUCCESS" in green/red depending on if it passed or failed. When isatty() returned false, it was impossible to tell if it passed or failed, but the software was pure garbage.
I don't entirely agree. When I do want colour (generally because I've taken the time to configure the program suitably for it), then I usually still want the colour when I pipe its output through a pager. `diff` is the canonical example.
Edit: Another comment¹ points out pipetty² as a workaround, so I learned something useful today.
Now if we could only agree on a standard to do this using environment variables... Unfortunately, the most widely known "standard" [0], is still very rarely supported.
> The terminal is capable of color and should be able to print color when instructed. NO_COLOR is a hint to the software running in the terminal to suppress addition of color, not to the terminal to prevent any color from being shown.
> It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author.
Go into the settings, set “no colour” and it just strips all the escape codes from the stream?
Or just outright ignore them?
I guess it feels weird to want to make this the problem of every CLI application developer.
Or use an existing one like ansi-mono
Good joke.
Not using colour is no work at all. Using colour correctly is a fair bit of work, and few programs do so; practically none check whether the terminal background is dark or light before emitting a dark blue or light yellow.
I also don’t think anyone is asking you to go change all the software in the world to support NO_COLOR=1 just to help people out.
I do think it would be great if the next time you thought about putting a little colour in your application that you consider supporting $NO_COLOR to disable it. It would help me and others out if I ever found myself using your software.
I do agree that the terminal you suggest (if it existed and were common) _would_ be better than NO_COLOR=1 but I hope you can also understand we don’t live in that world, and that the “best” solution in one way, isn’t always the best way to help people out.
Finally, I hope very much that you can think about accessibility in the future: asking the disabled to work harder is not a kindness- it may be unrealistic to do anything else, but you can try to make it as easy as you can, and that is a kindness.
> "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.
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.
Blue on black is typically very 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.
Then, just use the user's color scheme? This is an argument against using 256-color or terminal RGB, not against color altogether.
Your ship has sailed.
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.
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.
This is an argument against using 256-color or true color though.
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.
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.
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.
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.
Try yellow on white.
(Dark blue on white is quite usable.)
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.)
Vim was there too, under 'vim'.
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.
Just one example is the default yashrc that is used by the Watanabe shell: https://github.com/magicant/yash/blob/trunk/share/initializa...
(Yes, this is the default, in the absence of a yashrc file, not the sample yashrc file.)
:set background=dark should fix that.
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!?)
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.
Beyond that this is a feature that some people want i guess.. I could ask every website to give me a NO_COLOR mode as well, but they don't. Instead you can greyscale at the OS level or the terminal emulator level if you need it.
Perhaps more websites than you realise: I use the reader view whenever I can, which is a little bit like $NO_COLOR for websites.
Browsers also tend to widely have support for disabling style sheets and support for overrides, and wide support is more important than theoretical solutions.
I do think it would be great if terminals had broad support for this kind of accessibility feature, but they don’t, and I think adding it is much harder than you think.
> Instead you can greyscale at the OS level or the terminal emulator level if you need it.
This doesn’t work very well in practice unfortunately because the intensity differs so widely and my terminal settings don’t help when I have to look at someone else’s screen.
So while we wait for operating systems and terminal emulators to add more support for the disabled, maybe if you don’t mind, the next time you think about calling puts() with some color-codes in it you could just pretty-please check if $NO_COLOR is set?
A better match would be print (view) where the website does get to specify the style (although some browsers add their own heuristics because most websites don't).
To me this simply reads, "If your application deals with colour, consider your user, and please also consider this standard".
In particular the line "If your software outputs colour by default, please consider not doing so", on one hand comes across as opinionated, on the other hand I mostly interpret this as a call to not have coloured output as a default without having first considered an easy way to disable it, which is sensible.
I like colours in my terminal, and have included them in most of my non-trivial work; I have also added NO_COLOR because I think it's a nice informal standard, but more importantly I support the --color=<auto|never|always> GNU standard.
The part where I lack a bit is the customisability; I'm not too sure how to use terminal themes, so I have been using absolute colour sequences instead. I need to look that up...
On the other hand, every single editor from Vim to full blown IDEs has an absolutely braindead idea of what syntax highlighting should be.
Some keywords are useless noise (public, final, const, struct) while other keywords are more important - but usually they are all behind a single syntax rule called "keyword". I want to configure each one individually so I can visually scan code faster. IntelliJ has the right idea with semantic highlighting and I think every editor these days has a rainbow parentheses plugin that helps deciphering long expressions.
Personally, I've fixed this with a few Vim keybinds allowing me to dynamically highlight things that are important at the moment.
For non-interactive use I either use Vim as a pager or pipe to a small script which highlights what I want to see.
Details differ per language; but most syntax files declare fine-grained syntax rule which are then linked to "Keyword" highlight or whatnot later, but there's nothing preventing you from clearing the fine-grained syntax rules (or just defining your own).
FORCE_COLOR is a de facto variable without a de facto meaning, so I don't bother to support it.
I'll give them the benefit of the doubt that they simply didn't search for existing solutions, but when it was pointed out to them they really should have said "ok yeah you should use that".
Instead it isn't even mentioned on their website.
I also prefer this to having a fucked up scrollback.
I use a desaturated theme for coding: bg #f6f6f3, fg #303030, keyword #303060, etc (and a dark variant for the late sessions). I have a little bit more saturation in the terminal (eg #3465a4 for blue) but it's definitely on the toned down side, compared e.g. to the xterm or Terminal.app defaults.
Remember when MS Windows allowed you to change the color of every single UI element? Some of these color schemes were really beautiful. We should go back to user-themeable UIs.
I keep my monitors on as low brightness as i can without losing color and I end up using high saturation themes to make things more clear.
My other screen is a Thinkpad X230 and there's no definition of "too bright" that fits it, even at max brightness.
I already have some code in my own shell to wrap everything in a PTY (ironically to add colour: highlight stderr in red) but I could just as easily do the opposite and strip all colour escape sequences.
* All color schemes shall have the 15 colors that are not the background contrast well with the background.
* Terminal applications shall not specify white or black as the foreground color.
* Terminal applications shall not specify the background color.
* Terminal applications shall not output escape codes when piping or otherwise being used programmatically.
TFA seems to have pretty serious issues with color in general, so I'm curious to know from those here if the rules above would address your complaints or if there's something more going on that I'm just missing.
High-color terminals and apps beak out of the 16-color limit. Changing my “color theme” when someone wants to look at my screen sounds like more work than typing NO_COLOR=1. If I need to look at someone else’s screen what can I possibly do about their choice of colors and terminal emulators?
If you prefer no colors in your environment that's fine and you can probably configure it that way, but I don't think no color as a global default makes sense.
I also don't agree with the assumption that color carries information. Or rather, that you use it as such. The visual system uses different areas as markers. Color/high-lighting makes it easier to e.g. jump to the beginning of a function. But it would confuse you when used to convey semantics, e.g. when using color to distinguish between "if" as the start of a conditional statement and as an identifier. At least, that's what the Stroop task suggests might happen.
Unfortunately, calling it colorless would be exactly the wrong name for it!
(Or https://github.com/jwilk/pagerboy, which supports pagers other than less.)
The associated program 'ansi2txt' could also solve a similar problem for me from the other way round: I tend to have grep aliased to 'grep --color=always', simply because often I'm going to pipe the results to 'less' and I still want the colors. But this sometimes trips me up if I have a series of greps: The first grep output has color codes, making the followup greps fail. If grep could be made to strip out color codes prior to running, everything would work just as expected.
In general, if you're running a series of connected commands, it's only the last one that you want to get the colors from, with the special case exception of when the last command is 'less' - in which case, the next-to-last one should keep the colors. All ways that make this happen automatically are useful!
I don't understand this sentiment. As well say "it should be up to the user what the function of the software is, not the software author". If you don't like what a particular piece of software is doing, fork it and fix it, or replace it.
(To be clear -- I support the idea of `NO_COLOR` and other standards generally, and I strive to implement relevant standards when I can. I just think the above sentiment is bananas).
This kind of one-off setting like in the OP would make it a tad more usable.
chalk.bgHex('#DEADED').underline('Hello, world!')FORCE_COLOR was the first we had found that was also present in other Unix utilities and thus the one that won.
screen? white on black. give users easy option of overriding the text colors, styles and fonts
paper? black on white
wise rule of thumb. any exceptions should be a clear net win in the context/domain
This is effectively config. Should we export all of /etc/* into environment variables too? One variable per configurable thing?
2022: https://news.ycombinator.com/item?id=30483417 (201 comments)
2019: https://news.ycombinator.com/item?id=21171274 (9 comments)
2018: https://news.ycombinator.com/item?id=16322116 (53 comments)
if os.environ.get("NO_COLORS"): ...
if [ "$NO_COLORS" ]; ...
if [ "${NO_COLORS:-}" ]; ...
I have tried NO_SLOPPY_GRAMMAR=1, but I still get meaningless text about users adopting a standard and me not outputting color if my software does.