7 ms·

Do be sure to at least consider supporting no colour! http://no-color.org http://no-color.org

gitgud 8y ago
What a great idea for a standard, so the tool will check the NO_COLOR environment variable, to see if it should display color.
barrowclift 8y 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.
- rektide 8y ago
  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.
  - barrowclift 8y ago
    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!
- vanattab 8y ago
  My guess is the ansi color escape codes mess with peoples parsing code of the output when scripting.
  - wruza 8y ago
    All sane tools check if output isatty(3) before doing that.
    - abstractbeliefs 8y ago
      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.
      - wruza 8y ago
        Many who? Did I miss the arrival of new “Move Fast Etc” era into unix cli?
        abstractbeliefs 8y ago
        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.
    - masukomi 8y ago
      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.
- wruza 8y ago
  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.
- pravus 8y ago
  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).
  - scrollaway 8y ago
    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.
    - laumars 8y ago
      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.
    - pravus 8y ago
      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.
- JackCh 8y ago
  Colorless is not my cup of tea, but here is one perspective I read a few years ago: http://www.linusakesson.net/programming/syntaxhighlighting/index.php http://www.linusakesson.net/programming/syntaxhighlighting/i... HN discussion: https://news.ycombinator.com/item?id=3717303 https://news.ycombinator.com/item?id=3717303
  - pure-awesome 8y ago
    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 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.
    - Too 8y ago
      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.
    - delinka 8y ago
      "...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.
ggreer 8y ago
I don't understand why this is a standard. First: It requires that every command line tool add support for this environment variable. It may not be much effort for each project, but it adds up to a ton of developer time. Even if this standard gains traction, some apps will slip through the cracks. So in the success case, many users will still be annoyed that one or two of their tools print colors when they shouldn't. Second: As the FAQ on that page mentions, people can configure their terminal emulators to squelch color. NO_COLOR only matters for users who want color in some applications and not others. In that case, are certain applications supposed to refuse supporting NO_COLOR? Will all users want the same set of programs to behave that way? Are users supposed to unset NO_COLOR before running those programs? At that point, it seems like a more complex version of using some aliases that add --color=never (or whatever the appropriate flag is). Or if the user prefers to disable color by default, they could set $TERM to "xterm-old" and alias their favorite commands to add --color=always. Either way, there's no need for another environment variable. Really though, this seems like it should be a feature of the shell or the terminal emulator. Does the process name match certain patterns? Pass color codes through. No? Strip them. That would solve the problem for all programs past, present, and future. And total development effort would likely be less than that needed to implement NO_COLORS in every command line tool.
- abstractbeliefs 8y ago
  I'll speak for my case specifically: a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. I think it's apparent that this isn't something you're really keen to support in ag in the few times I've seen you talk about it, so feel free to close the PR I have open there rather than leave it hanging without any reply. https://github.com/ggreer/the_silver_searcher/pull/1207 https://github.com/ggreer/the_silver_searcher/pull/1207
  - the_af 8y ago
    > a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. Your use case seems perfectly valid to me, but how would NO_COLOR help you? Wouldn't it suppress all color in all programs when it's set? Assuming everyone gets on board, of course.
samatman 8y ago
| sed -e /\x1b\[[0-9;]+m// ^ I have not run the above program, only proven it to be correct.
- laumars 8y ago
  Sadly that only removes 1 of the 3 methods of escaping terminal colours. Plus there is also the risk of it removing other SGR (Select Graphic Rendition) escape codes such as underline. That latter bug might be an acceptable casualty though.
  - samatman 8y ago
    It was meant to remove underline, bold, dim, and even blink. Are there xterm codes for generating terminal color that don't end in m? It handily covers 8/88/256/24bit. What else is needed?
    - laumars 8y ago
      24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes* then it's a pretty minor additional to your regex. * Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.
      - samatman 8y ago
        I'm still looking for the use of ":" in xterm codes, but already discovered that this is a thing: "\033]11;#53186f\007" So, bare minimum, I'll need to include # in future. you can /generate/ 24 bit color using only ; and digits... When filtering ANSI I'm usually streaming the result to something that expects pure ASCII, and tuning sed to only accept two escape codes would be a pain in the neck.
        laumars 8y ago
        ISO 8613-6 uses colons. Admittedly it's a less supported standard. Sadly handling terminal escape codes is one of those impossibly painful jobs. Heck, often even the terminals don't seem to support the escape codes they have documented or the documentation is so poor that you're basically left with trial and error (or a shit load of hex dumps to trawl through if you're lucky). eg I've wasted hours trying to get Kitty specific escape codes working on that terminal emulator before giving up. I'm investing a lot of effort at the moment learning escape codes because I'm writing a new $SHELL which is designed to have rich media support even in $TERM's which don't support rich content. But I do still have support to convert the $SHELL back into a black and white console (I even have an option to strip colour from the STDOUT (even when pipelined) of all processes negating the need for your sed command. However that feature hasn't yet been committed back to the master branch.
arsham 8y ago
There is a --no-colour/--no-color argument you can pass.
notinventedhear 8y ago
+1 for NO_COLOR. For example, yellow text on a dull yellow background? No thanks. For years I've just wrapped commands on bash to strip the colour control-codes from stdout. function monochrome() { "$@" | sed -r "s/[[:cntrl:]]\[[0-9]{1,3}m//g" }
teamhappy 8y ago
Why wouldn't you just write a command line tool that strips the color escapes and then set up aliases like alias ag='ag | nocolor' or whatever. Seems much easier than trying to convince every developer out there to support your environment variable.
notheguyouthink 8y ago
I'm confused, with a tagline like "grep with colors!", wouldn't you just use grep if you don't want colors? This feels like complaining that Spotify doesn't have a silent mode for people who dislike sound. /shrug
masukomi 8y ago
this seems a far worse solution than pushing for a standard of encouraging apps to support --no-color I think there are FAR fewer people who want it off everywhere by default than people who want it off occasionally having all the arguments to your app be handling via dash args EXCEPT the one for color is non-standard, harder to explain in the docs, introduces an inconsistency to how your app is controlled, etc., etc...
deleted 8y ago
[deleted]

What a great idea for a standard, so the tool will check the NO_COLOR environment variable, to see if it should display color.

barrowclift 8y 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.

rektide 8y ago
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.
- barrowclift 8y ago
  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!
vanattab 8y ago
My guess is the ansi color escape codes mess with peoples parsing code of the output when scripting.
- wruza 8y ago
  All sane tools check if output isatty(3) before doing that.
  - abstractbeliefs 8y ago
    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.
    - wruza 8y ago
      Many who? Did I miss the arrival of new “Move Fast Etc” era into unix cli?
      - abstractbeliefs 8y ago
        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.
  - masukomi 8y ago
    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.
wruza 8y ago
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.
pravus 8y ago
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).
- scrollaway 8y ago
  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.
  - laumars 8y ago
    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.
  - pravus 8y ago
    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.
JackCh 8y ago
Colorless is not my cup of tea, but here is one perspective I read a few years ago: http://www.linusakesson.net/programming/syntaxhighlighting/index.php http://www.linusakesson.net/programming/syntaxhighlighting/i... HN discussion: https://news.ycombinator.com/item?id=3717303 https://news.ycombinator.com/item?id=3717303
- pure-awesome 8y ago
  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 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.
  - Too 8y ago
    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.
  - delinka 8y ago
    "...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.

ggreer 8y ago

I don't understand why this is a standard. First: It requires that every command line tool add support for this environment variable. It may not be much effort for each project, but it adds up to a ton of developer time. Even if this standard gains traction, some apps will slip through the cracks. So in the success case, many users will still be annoyed that one or two of their tools print colors when they shouldn't. Second: As the FAQ on that page mentions, people can configure their terminal emulators to squelch color. NO_COLOR only matters for users who want color in some applications and not others. In that case, are certain applications supposed to refuse supporting NO_COLOR? Will all users want the same set of programs to behave that way? Are users supposed to unset NO_COLOR before running those programs? At that point, it seems like a more complex version of using some aliases that add --color=never (or whatever the appropriate flag is). Or if the user prefers to disable color by default, they could set $TERM to "xterm-old" and alias their favorite commands to add --color=always. Either way, there's no need for another environment variable. Really though, this seems like it should be a feature of the shell or the terminal emulator. Does the process name match certain patterns? Pass color codes through. No? Strip them. That would solve the problem for all programs past, present, and future. And total development effort would likely be less than that needed to implement NO_COLORS in every command line tool.

abstractbeliefs 8y ago
I'll speak for my case specifically: a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. I think it's apparent that this isn't something you're really keen to support in ag in the few times I've seen you talk about it, so feel free to close the PR I have open there rather than leave it hanging without any reply. https://github.com/ggreer/the_silver_searcher/pull/1207 https://github.com/ggreer/the_silver_searcher/pull/1207
- the_af 8y ago
  > a lot of programs I use have varying levels of colour-by-default, but I don't want that. What I want is to have them all off, except the ones that actually add value. Your use case seems perfectly valid to me, but how would NO_COLOR help you? Wouldn't it suppress all color in all programs when it's set? Assuming everyone gets on board, of course.

samatman 8y ago

| sed -e /\x1b\[[0-9;]+m// ^ I have not run the above program, only proven it to be correct.

laumars 8y ago
Sadly that only removes 1 of the 3 methods of escaping terminal colours. Plus there is also the risk of it removing other SGR (Select Graphic Rendition) escape codes such as underline. That latter bug might be an acceptable casualty though.
- samatman 8y ago
  It was meant to remove underline, bold, dim, and even blink. Are there xterm codes for generating terminal color that don't end in m? It handily covers 8/88/256/24bit. What else is needed?
  - laumars 8y ago
    24bit uses the colon character as well. So if you're wanting to remove all SGR escape codes* then it's a pretty minor additional to your regex. * Personally I quite like the bold and reset SGRs even when I don't want the term colourised. Bold can highlight text without drawing your attention away from the main body of the terminal.
    - samatman 8y ago
      I'm still looking for the use of ":" in xterm codes, but already discovered that this is a thing: "\033]11;#53186f\007" So, bare minimum, I'll need to include # in future. you can /generate/ 24 bit color using only ; and digits... When filtering ANSI I'm usually streaming the result to something that expects pure ASCII, and tuning sed to only accept two escape codes would be a pain in the neck.
      - laumars 8y ago
        ISO 8613-6 uses colons. Admittedly it's a less supported standard. Sadly handling terminal escape codes is one of those impossibly painful jobs. Heck, often even the terminals don't seem to support the escape codes they have documented or the documentation is so poor that you're basically left with trial and error (or a shit load of hex dumps to trawl through if you're lucky). eg I've wasted hours trying to get Kitty specific escape codes working on that terminal emulator before giving up. I'm investing a lot of effort at the moment learning escape codes because I'm writing a new $SHELL which is designed to have rich media support even in $TERM's which don't support rich content. But I do still have support to convert the $SHELL back into a black and white console (I even have an option to strip colour from the STDOUT (even when pipelined) of all processes negating the need for your sed command. However that feature hasn't yet been committed back to the master branch.

arsham 8y ago

There is a --no-colour/--no-color argument you can pass.

notinventedhear 8y ago

+1 for NO_COLOR. For example, yellow text on a dull yellow background? No thanks. For years I've just wrapped commands on bash to strip the colour control-codes from stdout. function monochrome() { "$@" | sed -r "s/[[:cntrl:]]\[[0-9]{1,3}m//g" }

teamhappy 8y ago

Why wouldn't you just write a command line tool that strips the color escapes and then set up aliases like alias ag='ag | nocolor' or whatever. Seems much easier than trying to convince every developer out there to support your environment variable.

notheguyouthink 8y ago

I'm confused, with a tagline like "grep with colors!", wouldn't you just use grep if you don't want colors? This feels like complaining that Spotify doesn't have a silent mode for people who dislike sound. /shrug

masukomi 8y ago

this seems a far worse solution than pushing for a standard of encouraging apps to support --no-color I think there are FAR fewer people who want it off everywhere by default than people who want it off occasionally having all the arguments to your app be handling via dash args EXCEPT the one for color is non-standard, harder to explain in the docs, introduces an inconsistency to how your app is controlled, etc., etc...

deleted 8y ago

[deleted]