Hacker News Reader

Comment by noitpmeder | Hacker News Reader

They address this FAQ on the linked page:

> 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.

View on HN

Is there some reason why we can’t just implement this once in each terminal?

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.

I want colour, in certain places, under my control. I don't want every random tool spewing confetti.

So you want every developer to spend time on both color and non-color options but are not willing to contribute a patch for that?

I have no problem contributing patches, but nothing I currently use regularly is ill-behaved.

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.

Aside from your uncharitable interpretation: it is really not difficult or time-consuming to support this. It's just setting and checking a single boolean flag, in fact it may simply just be a few lines at startup if the tool already supports color options via cli args.

Indeed, if one uses the termcap or terminfo libraries (or the likes of unibilium) to obtain the control sequences for colour from those databases, instead of hardwiring them into the source code of print statements, one gets the TERM=dumb convention implemented entirely for free.

In this case it seems pretty easy to contribute a patch? Mature projects have unit and screendiff test suites that need to be updated and extended to verify the new case, so it might not be THAT easy even for a trivial change.

> Mature projects have unit and screendiff test suites

Good joke.

You could copy an existing terminfo entry and remove the colour.

Or use an existing one like ansi-mono

I read the page before commenting and it didn't address my point. That answer is about why it's not satisfactory to simply disable all color in the terminal. I'm talking about adding a color whitelist/blacklist feature to a terminal emulator.

You don't know which process it is. The color producing program can be embedded in a script or running in an ssh session.

Reply on news.ycombinator.com