{"thread":{"id":"47952","subject":"[RFC PATCH] color: respect the $NO_COLOR convention","startedAt":"2018-03-01T16:44:30Z","lastAt":"2018-03-05T02:24:26Z","messageCount":6,"participants":["Leah Neukirchen","Junio C Hamano","brian m. carlson"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"340733","messageId":"87zi3reoez.fsf@gmail.com","threadId":"47952","inReplyTo":null,"subject":"[RFC PATCH] color: respect the $NO_COLOR convention","fromName":"Leah Neukirchen","fromEmail":"leah@vuxu.org","sentAt":"2018-03-01T16:44:20Z","receivedAt":"2018-03-01T16:44:30Z","isPatch":true,"sender":{"key":"leah@vuxu.org","avatar":null},"body":"When the NO_COLOR environment variable is set to any value, default to\ndisabling color, i.e. resolve 'auto' to false.\n\nNO_COLOR (http://no-color.org/) is a comprehensive approach to disable\ncolors by default for all tools:\n> All command-line software which outputs text with ANSI color added\n> should check for the presence of a NO_COLOR environment variable that,\n> when present (regardless of its value), prevents the addition of ANSI\n> color.\n\nSigned-off-by: Leah Neukirchen \n---\n\nThis is a first stab at implementing NO_COLOR for git, effectively\nmaking it then behave like before colors were enabled by default.\n\nI feel this should be documented somewhere, but I'm not sure where the\nbest place is. Perhaps in config.ui, or the Git environment variables\n(but they all start with GIT_).\n\n color.c | 2 ++\n 1 file changed, 2 insertions(+)\n\ndiff --git a/color.c b/color.c\nindex d48dd947c..59e9c2459 100644\n--- a/color.c\n+++ b/color.c\n@@ -326,6 +326,8 @@ int git_config_colorbool(const char *var, const char *value)\n \n static int check_auto_color(void)\n {\n+\tif (getenv(\"NO_COLOR\"))\n+\t\treturn 0;\n \tif (color_stdout_is_tty < 0)\n \t\tcolor_stdout_is_tty = isatty(1);\n \tif (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {\n-- \n2.16.2\n"},{"id":"340734","messageId":"xmqqefl3iuvx.fsf@gitster-ct.c.googlers.com","threadId":"47952","inReplyTo":"87zi3reoez.fsf@gmail.com","subject":"Re: [RFC PATCH] color: respect the $NO_COLOR convention","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-01T17:10:58Z","receivedAt":"2018-03-01T17:11:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leah Neukirchen writes:\n\n> NO_COLOR (http://no-color.org/) is a comprehensive approach to disable\n> colors by default for all tools:\n\nThe list of software that supports that \"convention\" is, eh,\nrespectable. Is it really a \"convention\" yet, or yet another thing\nthe user needs to worry about?\n\n> diff --git a/color.c b/color.c\n> index d48dd947c..59e9c2459 100644\n> --- a/color.c\n> +++ b/color.c\n> @@ -326,6 +326,8 @@ int git_config_colorbool(const char *var, const char *value)\n> \n> static int check_auto_color(void)\n> {\n> +\tif (getenv(\"NO_COLOR\"))\n> +\t\treturn 0;\n\nOur convention often calls for CONFIG_VAR=false to mean \"I do not\nwant to see what CONFIG_VAR wants to do done\", i.e.\n\n\tNO_COLOR=false git show\n\nwould show colored output if there is no other settings. But this\ncode contradicts the convention, deliberately because that is what\nno-color.org wants. Makes me wonder if that convention is worth\nfollowing in the first place.\n\n> \tif (color_stdout_is_tty < 0)\n> \t\tcolor_stdout_is_tty = isatty(1);\n> \tif (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {\n\nAccording to no-color.org's FAQ #2, NO_COLOR should affect only the\n\"default\" behaviour, and should stay back if there is an explicit\nend-user configuration (or command line override). And this helper\nfunction is called only from want_color() when their is no such\nhigher precedence setting, which is in line with the recommendation.\n\nWhich is good.\n"},{"id":"340735","messageId":"87efl3emlm.fsf@vuxu.org","threadId":"47952","inReplyTo":"xmqqefl3iuvx.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH] color: respect the $NO_COLOR convention","fromName":"Leah Neukirchen","fromEmail":"leah@vuxu.org","sentAt":"2018-03-01T17:23:33Z","receivedAt":"2018-03-01T17:23:41Z","isPatch":true,"sender":{"key":"leah@vuxu.org","avatar":null},"body":"Junio C Hamano writes:\n\n> Leah Neukirchen writes:\n>\n>> NO_COLOR (http://no-color.org/) is a comprehensive approach to disable\n>> colors by default for all tools:\n>\n> The list of software that supports that \"convention\" is, eh,\n> respectable. Is it really a \"convention\" yet, or yet another thing\n> the user needs to worry about?\n\nYou are right in calling this out an emerging new thing, but the\nsecond list of that page proves that it will be useful to settle on a\ncommon configuration, and my hope is by getting a few popular projects\non board, others will soon follow. It certainly is easy to implement,\nand rather unintrusive. Users which don't know about this feature are\ncompletely unaffected.\n\n>> \tif (color_stdout_is_tty < 0)\n>> \t\tcolor_stdout_is_tty = isatty(1);\n>> \tif (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {\n>\n> According to no-color.org's FAQ #2, NO_COLOR should affect only the\n> \"default\" behaviour, and should stay back if there is an explicit\n> end-user configuration (or command line override). And this helper\n> function is called only from want_color() when their is no such\n> higher precedence setting, which is in line with the recommendation.\n>\n> Which is good.\n\nYes, I took care of that. Should this also be tested? It doesn't\nquite fit into the setting of t4026-color.sh I think.\n\nThanks,\n-- \nLeah Neukirchen http://leah.zone\n"},{"id":"340749","messageId":"xmqq8tbbhayi.fsf@gitster-ct.c.googlers.com","threadId":"47952","inReplyTo":"87efl3emlm.fsf@vuxu.org","subject":"Re: [RFC PATCH] color: respect the $NO_COLOR convention","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-01T19:06:45Z","receivedAt":"2018-03-01T19:06:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Leah Neukirchen writes:\n\n> You are right in calling this out an emerging new thing, but the\n> second list of that page proves that it will be useful to settle on a\n> common configuration, and my hope is by getting a few popular projects\n> on board, others will soon follow. It certainly is easy to implement,\n> and rather unintrusive. Users which don't know about this feature are\n> completely unaffected.\n\nThere certainly is chicken-and-egg problem there. Even though I\npersonally prefer not to see overuse of colors, I am not sure if\nwe the Git community as a whole would want to be involved until it\ngets mainstream.\n\n>>> \tif (color_stdout_is_tty < 0)\n>>> \t\tcolor_stdout_is_tty = isatty(1);\n>>> \tif (color_stdout_is_tty || (pager_in_use() && pager_use_color)) {\n>>\n>> According to no-color.org's FAQ #2, NO_COLOR should affect only the\n>> \"default\" behaviour, and should stay back if there is an explicit\n>> end-user configuration (or command line override). And this helper\n>> function is called only from want_color() when their is no such\n>> higher precedence setting, which is in line with the recommendation.\n>>\n>> Which is good.\n>\n> Yes, I took care of that. Should this also be tested? It doesn't\n> quite fit into the setting of t4026-color.sh I think.\n\nIt probably fits much better in t7006, I would suspect. Earlier,\nsetting color.ui to auto meant the output is colored when run under\ntest_terminal, but with this new environment set, the output will\nhave to be bland.\n"},{"id":"340993","messageId":"20180304223925.GA808005@genre.crustytoothpaste.net","threadId":"47952","inReplyTo":"xmqq8tbbhayi.fsf@gitster-ct.c.googlers.com","subject":"Re: [RFC PATCH] color: respect the $NO_COLOR convention","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-03-04T22:39:25Z","receivedAt":"2018-03-04T22:39:38Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Thu, Mar 01, 2018 at 11:06:45AM -0800, Junio C Hamano wrote:\n> Leah Neukirchen writes:\n> \n> > You are right in calling this out an emerging new thing, but the\n> > second list of that page proves that it will be useful to settle on a\n> > common configuration, and my hope is by getting a few popular projects\n> > on board, others will soon follow. It certainly is easy to implement,\n> > and rather unintrusive. Users which don't know about this feature are\n> > completely unaffected.\n> \n> There certainly is chicken-and-egg problem there. Even though I\n> personally prefer not to see overuse of colors, I am not sure if\n> we the Git community as a whole would want to be involved until it\n> gets mainstream.\n\nAs a note, turning off color can improve accessibility for some people.\nI have a co-worker who has deuteranomaly and virtually all colored text\nat the terminal poses readability problems. It would be beneficial if\nhe could just set NO_COLOR=1 in his environment and have everything just\nwork.\n\nFor this reason, I'm in favor of taking this patch, assuming it comes\nwith tests.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\nhttps://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"340996","messageId":"xmqqvaeb9s4t.fsf@gitster-ct.c.googlers.com","threadId":"47952","inReplyTo":"20180304223925.GA808005@genre.crustytoothpaste.net","subject":"Re: [RFC PATCH] color: respect the $NO_COLOR convention","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-05T02:24:18Z","receivedAt":"2018-03-05T02:24:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> As a note, turning off color can improve accessibility for some people.\n> I have a co-worker who has deuteranomaly and virtually all colored text\n> at the terminal poses readability problems. It would be beneficial if\n> he could just set NO_COLOR=1 in his environment and have everything just\n> work.\n>\n> For this reason, I'm in favor of taking this patch, assuming it comes\n> with tests.\n\nOh, I agree 100% the world would be a better place if there already\nis an established way to turn off all colors, instead of having to\nrun around and setting tool specific configuration like LS_COLORS\netc. for 42 different tools one uses during one's daily life. I\njust am not getting the feeling this no-color.org's effort is the\none. We already have a way specific to our project already (i.e.\nconfiguration variables), so if we adopt NO_COLOR but other people\ndo not universally support it (and they support something else),\nwe'd end up having to maintain yet another knob that only a handful\nof projects understand forever, and that is where my reluctance\ncomes from.\n"}]}