Hacker News new | ask | show | jobs
by barrowclift 2935 days ago
Genuinely curious, why do some developers prefer not having colors for ls, grep, etc.? no-color.org mentions that many users prefer having colors disabled, but didn't list any reasons why.
5 comments

I don't find that they add anything. I feel like they make it harder for me to do a coherent read of the screen, to suck in all the text & process it. I have my own mental algorithms to pick out relevant things, and having a bunch of glaringly contrasting blocks of color glaring out of the terminal at me just makes it harder to slurp in the screen. I don't want that segmentation. It's awful.

And the color themes for the terminal are godawful. No matter how you spin 16 colors, how solarized or other, everyone is kind of chained more or less to that attrocious 16 color pallet, which is always going to be way way higher contrast or low-fi than something like a vim theme that can pick some complementary colors to work with.

Colors feel like my terminal punching me in the face. No thanks.

Also have you ever logged into ubuntu? Holy shit colors were a TERRIBLE idea.

That makes sense. In a way, it's like they're mental "speed bumps" that disrupt reading the text. I can certainly see why those "bumps" would be aggravating, thanks for the insight!
Colorless is not my cup of tea, but here is one perspective I read a few years ago: http://www.linusakesson.net/programming/syntaxhighlighting/i...

HN discussion: https://news.ycombinator.com/item?id=3717303

I disagree with the author's claim that "A splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text."

Funny enough, I've found that adding syntax highlighting to even normal English text makes it more readable. I sometimes turn on a random language's syntax highlighting in e.g. Notepad++ even if the choice of colouring is basically nonsense.

In the article you link, apart from the green on grey, the little example paragraph is actually very nice and readable.

Something like http://www.beelinereader.com/individual would probably make things easier for me, though it costs money.

The other issue is that it is too uniform. I like how syntax highlighting tends to make random patterns which kind of looks like pictures in the code - it makes it much easier for me to navigate, and figure out where I was and where I'm going.

There was a link to a study here on HN some year(s) ago where they alternated the colour of each sentence in a text and found the reading speed to be increased. Probably similar effect as making text columns more narrow instead of using the full width of your screen, its easier to navigate and uts easier to read a whole chunk at once instead of word by word.
"...a splash of colour may grab the reader's attention, but it will inevitably decrease the legibility of the text."

This depends entirely on the content of the text. Stories, fiction, non-fiction, reference material ... information where one human is intending to communicate with another human should limit use of color.

For source code, that humans do read but is intended to be parsed and compiled by a computer, I'm not assembling (in my head) the whimsical trials of a protagonist - I need to see structure; color gives me a quicker overview of the structure of a line, function, class, etc.

My guess is the ansi color escape codes mess with peoples parsing code of the output when scripting.
All sane tools check if output isatty(3) before doing that.
Many don't though. Typically, though, the place to add no-color is even on the same line as this test and is a very cheap add, so anyone looking to add it would do well to consider adding both.
Many who? Did I miss the arrival of new “Move Fast Etc” era into unix cli?
There's a bunch even on that list. I had a look at ffind, the second on the page and found nothing to test if the output was tty or otherwise.

Generally though, I'm not out to point fingers, it's just a fact that not all software is complete and bug-free. We're all people with limited time and we don't have the attention to detail that dealing with the maliciously compliant children that computers are takes.

as @abstractbeliefs said, there are a lot that don't, but personally i hate it when apps do that because it removes my ability to actually maintain the colors through pipe chains. It's much harder to convince an app to maintain color through a pipe from an app that does this than it is to remove color from an app that doesn't pay attention to tty or not.
My terminal has non-default long-battle-tested background and foreground colors, and I barely pay an attention to the entire palette, so coloring works like acid. Some colors are simply incompatible, so tuning them is meaningless. Imagine e.g. any dark blue on medium grey.

What I think would be good (for me at least) is not colors, but sort of markup, like bold or underline, which is available in terminal as seen in man pages and PS1. I usually make them bold and compatible colored.

I turned most colors off many years ago. For me it was because several tools (especially ls) used colors that were very hard to distinguish with my terminal background. I found myself spending too much time trying to figure out what was on my screen.

Another bonus is that I don't feel cheated when I log into systems that don't support colors (*BSD, Solaris, etc). Everything just looks normal to me. Even non-syntax highlighted vi (not vim).

The tools don't exactly choose the color. They choose a color name from a palette. Your terminal's theme defines that palette.

If your terminal has a background very close to one of the colors on that palette, that is a theme problem, not an app problem.

This was a long time ago before terminal emulators had themes and I also did a lot of work on actual terminals (monochrome hardware) and the console (black background with gray text). Even my current emulator doesn't support "themes". I have to set each color register individually in the .Xresources file. On modern hardware this works fine, but years ago the quality of CRTs was such that you couldn't guarantee brightness and color levels across devices.

Do you remember the days of X Modelines? I still have the nightmares.

That's mostly true, but there are several different methods for sending colours via escape codes and the one you discuss is just the ANSI standard. There is also 265 colour palette and even true colours (defined via RGB values). However most tools will use the standard 8 colour palette or the extended 8x3 colour palette (8 colours across 3 different intensities) because they're supported on pretty much every terminal emulator (even on Windows's cmd.exe).

So it is possible for tools to choose colours by an exact RGB value, but typically they wont.

The other thing to remember is some tools can have their colours remapped. Even tools people might not expect to be able to. eg you can configure (via environmental variables IIRC) `ls` to have specific colours for specific inode types. However in my personal opinion it is a lot of faff for very little reward.