{"thread":{"id":"55714","subject":"[PATCH] help: colorize man pages","startedAt":"2021-05-18T01:02:08Z","lastAt":"2021-05-23T14:48:45Z","messageCount":33,"participants":["Felipe Contreras","brian m. carlson","Junio C Hamano","Ævar Arnfjörð Bjarmason","Jeff King","Igor Djordjevic"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"424797","messageId":"20210518010121.1350327-1-felipe.contreras@gmail.com","threadId":"55714","inReplyTo":null,"subject":"[PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T01:01:21Z","receivedAt":"2021-05-18T01:02:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Our man pages don't contain many useful colors (just blue links),\nmoreover, many people have groff SGR disabled, so they don't see any\ncolors with man pages.\n\nWe can set LESS_TERMCAP variables to render bold and underlined text\nwith colors in the pager; a common trick[1].\n\nBold is rendered as red, underlined as blue, and standout (messages and\nhighlighted search) as inverse magenta.\n\nThis only works when the pager is less, and the color.pager\nconfiguration is enabled, as well as color.ui.\n\n[1] https://unix.stackexchange.com/questions/119/colors-in-man-pages/147\n\nSigned-off-by: Felipe Contreras \n---\n builtin/help.c | 27 ++++++++++++++++++++++++++-\n color.h | 1 +\n 2 files changed, 27 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/help.c b/builtin/help.c\nindex bb339f0fc8..0119e833a8 100644\n--- a/builtin/help.c\n+++ b/builtin/help.c\n@@ -11,6 +11,7 @@\n #include \"config-list.h\"\n #include \"help.h\"\n #include \"alias.h\"\n+#include \"color.h\"\n \n #ifndef DEFAULT_HELP_FORMAT\n #define DEFAULT_HELP_FORMAT \"man\"\n@@ -253,10 +254,33 @@ static void exec_man_konqueror(const char *path, const char *page)\n \t}\n }\n \n+static void colorize_man(void)\n+{\n+\tif (!pager_use_color || !want_color(GIT_COLOR_UNKNOWN))\n+\t\treturn;\n+\n+\t/* Disable groff colors */\n+\tsetenv(\"GROFF_NO_SGR\", \"1\", 0);\n+\n+\t/* Bold */\n+\tsetenv(\"LESS_TERMCAP_md\", GIT_COLOR_BOLD_RED, 0);\n+\tsetenv(\"LESS_TERMCAP_me\", GIT_COLOR_RESET, 0);\n+\n+\t/* Underline */\n+\tsetenv(\"LESS_TERMCAP_us\", GIT_COLOR_BLUE GIT_COLOR_UNDERLINE, 0);\n+\tsetenv(\"LESS_TERMCAP_ue\", GIT_COLOR_RESET, 0);\n+\n+\t/* Standout */\n+\tsetenv(\"LESS_TERMCAP_so\", GIT_COLOR_MAGENTA GIT_COLOR_REVERSE, 0);\n+\tsetenv(\"LESS_TERMCAP_se\", GIT_COLOR_RESET, 0);\n+}\n+\n static void exec_man_man(const char *path, const char *page)\n {\n \tif (!path)\n \t\tpath = \"man\";\n+\n+\tcolorize_man();\n \texeclp(path, \"man\", page, (char *)NULL);\n \twarning_errno(_(\"failed to exec '%s'\"), path);\n }\n@@ -264,6 +288,7 @@ static void exec_man_man(const char *path, const char *page)\n static void exec_man_cmd(const char *cmd, const char *page)\n {\n \tstruct strbuf shell_cmd = STRBUF_INIT;\n+\tcolorize_man();\n \tstrbuf_addf(&shell_cmd, \"%s %s\", cmd, page);\n \texecl(SHELL_PATH, SHELL_PATH, \"-c\", shell_cmd.buf, (char *)NULL);\n \twarning(_(\"failed to exec '%s'\"), cmd);\n@@ -372,7 +397,7 @@ static int git_help_config(const char *var, const char *value, void *cb)\n \tif (starts_with(var, \"man.\"))\n \t\treturn add_man_viewer_info(var, value);\n \n-\treturn git_default_config(var, value, cb);\n+\treturn git_color_default_config(var, value, cb);\n }\n \n static struct cmdnames main_cmds, other_cmds;\ndiff --git a/color.h b/color.h\nindex 98894d6a17..d012add4e8 100644\n--- a/color.h\n+++ b/color.h\n@@ -51,6 +51,7 @@ struct strbuf;\n #define GIT_COLOR_FAINT\t\t\"\\033[2m\"\n #define GIT_COLOR_FAINT_ITALIC\t\"\\033[2;3m\"\n #define GIT_COLOR_REVERSE\t\"\\033[7m\"\n+#define GIT_COLOR_UNDERLINE\t\"\\033[4m\"\n \n /* A special value meaning \"no color selected\" */\n #define GIT_COLOR_NIL \"NIL\"\n-- \n2.31.1\n\n"},{"id":"424798","messageId":"YKMWL0iZLVl1KTrB@camp.crustytoothpaste.net","threadId":"55714","inReplyTo":"20210518010121.1350327-1-felipe.contreras@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-18T01:19:43Z","receivedAt":"2021-05-18T01:20:05Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-18 at 01:01:21, Felipe Contreras wrote:\n> Our man pages don't contain many useful colors (just blue links),\n> moreover, many people have groff SGR disabled, so they don't see any\n> colors with man pages.\n> \n> We can set LESS_TERMCAP variables to render bold and underlined text\n> with colors in the pager; a common trick[1].\n> \n> Bold is rendered as red, underlined as blue, and standout (messages and\n> highlighted search) as inverse magenta.\n> \n> This only works when the pager is less, and the color.pager\n> configuration is enabled, as well as color.ui.\n\nI think we should let the user decide whether they want to set this\nfeature themselves instead of setting it for them. For example, I have\nspecific colors set up with these environment variables, and I'd like\nGit to honor them without having to configure Git independently of less.\nI expect other users will expect Git's rendering of the manual pages to\nwork like other instances of man(1) on their system as well.\n\nAdditionally, using colors poses accessibility problems. I know someone\nwho, due to his colorblindness, finds terminal colors distracting and\nhard to read, and prefers not to use them at all. Even users who want\nto use them might find some colors to be too similar, and this patch\ndoesn't permit them to be configured.\n\nIn my particular case, despite having normal color vision, because I use\na transparent terminal which often results in a grey background, I find\nthe standard terminal red to be difficult to read, and so this patch\nwould result in a significant decrease in the readability of the manual\npages for me.\n\nSo overall I think I'd prefer if we didn't color manual pages for the\nuser.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"424812","messageId":"60a332fd22dad_14c8d4208ed@natae.notmuch","threadId":"55714","inReplyTo":"YKMWL0iZLVl1KTrB@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T03:22:37Z","receivedAt":"2021-05-18T03:22:44Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-18 at 01:01:21, Felipe Contreras wrote:\n> > Our man pages don't contain many useful colors (just blue links),\n> > moreover, many people have groff SGR disabled, so they don't see any\n> > colors with man pages.\n> > \n> > We can set LESS_TERMCAP variables to render bold and underlined text\n> > with colors in the pager; a common trick[1].\n> > \n> > Bold is rendered as red, underlined as blue, and standout (messages and\n> > highlighted search) as inverse magenta.\n> > \n> > This only works when the pager is less, and the color.pager\n> > configuration is enabled, as well as color.ui.\n> \n> I think we should let the user decide whether they want to set this\n> feature themselves instead of setting it for them. For example, I have\n> specific colors set up with these environment variables, and I'd like\n> Git to honor them without having to configure Git independently of less.\n> I expect other users will expect Git's rendering of the manual pages to\n> work like other instances of man(1) on their system as well.\n\nIt does respect them.\n\nThis would render the man page with the color specified in the\nenvironment, not the default of git.\n\n LESS_TERMCAP_md=$'\\e[1;33m' LESS_TERMCAP_me=$'\\e[m' git help git\n\n> Additionally, using colors poses accessibility problems. I know someone\n> who, due to his colorblindness, finds terminal colors distracting and\n> hard to read, and prefers not to use them at all.\n\n git -c color.ui=never help git\n\n> Even users who want to use them might find some colors to be too\n> similar, and this patch doesn't permit them to be configured.\n\nYes it does:\n\n LESS_TERMCAP_md=$'\\e[01;38;5;33m' git help git\n\n> In my particular case, despite having normal color vision, because I use\n> a transparent terminal which often results in a grey background, I find\n> the standard terminal red to be difficult to read, and so this patch\n> would result in a significant decrease in the readability of the manual\n> pages for me.\n\nIf you have LESS_TERMCAP_md set in your environment, it won't.\n\n-- \nFelipe Contreras\n"},{"id":"424904","messageId":"YKRSlFcFAcHcR3uY@camp.crustytoothpaste.net","threadId":"55714","inReplyTo":"60a332fd22dad_14c8d4208ed@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-18T23:49:40Z","receivedAt":"2021-05-18T23:49:48Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-18 at 03:22:37, Felipe Contreras wrote:\n> brian m. carlson wrote:\n> > I think we should let the user decide whether they want to set this\n> > feature themselves instead of setting it for them. For example, I have\n> > specific colors set up with these environment variables, and I'd like\n> > Git to honor them without having to configure Git independently of less.\n> > I expect other users will expect Git's rendering of the manual pages to\n> > work like other instances of man(1) on their system as well.\n> \n> It does respect them.\n> \n> This would render the man page with the color specified in the\n> environment, not the default of git.\n> \n> LESS_TERMCAP_md=$'\\e[1;33m' LESS_TERMCAP_me=$'\\e[m' git help git\n\nIt still doesn't work like other instances of man(1) on the system.\nWhile you claimed that \"that's a preference others don't share\", I'm\npretty certain that I'm not the only person who feels this way.\n\nThere's a big difference between Git coloring a Git UI, like a diff, and\nGit coloring a separate program that already has sensible, standard\ndefaults. A user who has not configured any color settings would\nprobably not want Git to render manual pages one way, cargo to render\nmanual pages a second way, and still other programs to render manual\npages in other, incompatible ways. We need to consider not only the\nimpact that our decisions have in a vacuum, but what results similar\ndecisions from other projects would produce in the software ecosystem as\na whole.\n\nWould you consider various projects coloring their respective manual\npages differently to be a desirable state of affairs?\n\n> > Additionally, using colors poses accessibility problems. I know someone\n> > who, due to his colorblindness, finds terminal colors distracting and\n> > hard to read, and prefers not to use them at all.\n> \n> git -c color.ui=never help git\n\nYes, but unfortunately, since you've colored the manual pages, they may\nbe hard to read for the user who needs to read them to learn about your\nconfiguration. This is great for you and me, who are already very\nfamiliar with Git and know how to do that without looking, but not great\nfor the novice colorblind user.\n\nFor similar reasons, colorizing help output in general is unhelpful\nbecause users cannot find the options to disable it.\n\nIn general, this is made worse because Git doesn't honor the unofficial\nbut widely supported NO_COLOR[0], so reading the documentation is\nobligatory.\n\n> > Even users who want to use them might find some colors to be too\n> > similar, and this patch doesn't permit them to be configured.\n> \n> Yes it does:\n> \n> LESS_TERMCAP_md=$'\\e[01;38;5;33m' git help git\n\nI should clarify that the patch doesn't permit them to be configured\nusing the normal Git mechanisms. For example, unless the user sets the\nenvironment variables, which take effect globally, they're stuck with\nthe colors that we've chosen here. Yes, they can specify a single\nenvironment variable before the command, but practically nobody will do\nthat.\n\nIt's my argument that the user doesn't want Git manual pages to be\ncolored differently than other manual pages on the system, but if you\nbelieve differently, then we should allow the user to configure the\ncolors that are used in the Git-specific context using Git standard\nmechanisms.\n\n> > In my particular case, despite having normal color vision, because I use\n> > a transparent terminal which often results in a grey background, I find\n> > the standard terminal red to be difficult to read, and so this patch\n> > would result in a significant decrease in the readability of the manual\n> > pages for me.\n> \n> If you have LESS_TERMCAP_md set in your environment, it won't.\n\nThe problem is, I don't always. I am on call for a set of hundreds of\nservers, only one of which has my shell configuration set up, so\ndefaults here matter. Moreover, because there are many novice users of\nGit, we should consider that for a decent number of users, they\nliterally won't know where to look in our documentation to make\nchanges, and therefore the defaults matter for them, too.\n\n[0] https://no-color.org/\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"424908","messageId":"xmqqfsyj1qe1.fsf@gitster.g","threadId":"55714","inReplyTo":"YKRSlFcFAcHcR3uY@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-19T01:08:54Z","receivedAt":"2021-05-19T01:08:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> In general, this is made worse because Git doesn't honor the unofficial\n> but widely supported NO_COLOR[0], so reading the documentation is\n> obligatory.\n\nI vaguely recall that we were contacted by NO_COLOR folks to be\nan early supporter of their cause to break the chicken-and-egg\nproblem they were hagving, and (unhelpfully) answered with \"sure,\nwhen we see enough people support it---otherwise we'd end up having\nto keep essentially a dead code that supports a convention that is\nnot all that useful\".\n\n> [0] https://no-color.org/\n\nI wonderr if it is just a matter of hooking into want_color(), like this?\n\n color.c | 7 ++++++-\n 1 file changed, 6 insertions(+), 1 deletion(-)\n\ndiff --git c/color.c w/color.c\nindex 64f52a4f93..2516ef7275 100644\n--- c/color.c\n+++ w/color.c\n@@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)\n \t * we always write the same value, but it's still wrong. This function\n \t * is listed in .tsan-suppressions for the time being.\n \t */\n-\n+\tstatic int no_color = -1;\n \tstatic int want_auto[3] = { -1, -1, -1 };\n \n \tif (fd < 1 || fd >= ARRAY_SIZE(want_auto))\n \t\tBUG(\"file descriptor out of range: %d\", fd);\n \n+\tif (no_color < 0)\n+\t\tno_color = !!getenv(\"NO_COLOR\");\n+\tif (no_color)\n+\t\treturn 0;\n+\n \tif (var < 0)\n \t\tvar = git_use_color_default;\n \n"},{"id":"424915","messageId":"YKRy6oPkgS6FMSZ0@camp.crustytoothpaste.net","threadId":"55714","inReplyTo":"xmqqfsyj1qe1.fsf@gitster.g","subject":"Re: [PATCH] help: colorize man pages","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-19T02:07:38Z","receivedAt":"2021-05-19T02:08:17Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-19 at 01:08:54, Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > In general, this is made worse because Git doesn't honor the unofficial\n> > but widely supported NO_COLOR[0], so reading the documentation is\n> > obligatory.\n> \n> I vaguely recall that we were contacted by NO_COLOR folks to be\n> an early supporter of their cause to break the chicken-and-egg\n> problem they were hagving, and (unhelpfully) answered with \"sure,\n> when we see enough people support it---otherwise we'd end up having\n> to keep essentially a dead code that supports a convention that is\n> not all that useful\".\n\nYeah, I seem to recall you were somewhat negative on it at the time, but\nI do personally find it useful, and someone on Twitter reminded me of\nit just today.\n\n> I wonderr if it is just a matter of hooking into want_color(), like this?\n> \n> color.c | 7 ++++++-\n> 1 file changed, 6 insertions(+), 1 deletion(-)\n> \n> diff --git c/color.c w/color.c\n> index 64f52a4f93..2516ef7275 100644\n> --- c/color.c\n> +++ w/color.c\n> @@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)\n> \t * we always write the same value, but it's still wrong. This function\n> \t * is listed in .tsan-suppressions for the time being.\n> \t */\n> -\n> +\tstatic int no_color = -1;\n> \tstatic int want_auto[3] = { -1, -1, -1 };\n> \n> \tif (fd < 1 || fd >= ARRAY_SIZE(want_auto))\n> \t\tBUG(\"file descriptor out of range: %d\", fd);\n> \n> +\tif (no_color < 0)\n> +\t\tno_color = !!getenv(\"NO_COLOR\");\n> +\tif (no_color)\n> +\t\treturn 0;\n> +\n> \tif (var < 0)\n> \t\tvar = git_use_color_default;\n> \n\nYeah, that will probably do it. I hadn't looked at it, but I assumed it\nwould be pretty easy, and it looks like it is.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"424918","messageId":"xmqq1ra3z23n.fsf@gitster.g","threadId":"55714","inReplyTo":"YKRy6oPkgS6FMSZ0@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-19T06:09:32Z","receivedAt":"2021-05-19T06:09:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> On 2021-05-19 at 01:08:54, Junio C Hamano wrote:\n>> \"brian m. carlson\" writes:\n>> \n>> > In general, this is made worse because Git doesn't honor the unofficial\n>> > but widely supported NO_COLOR[0], so reading the documentation is\n>> > obligatory.\n>> \n>> I vaguely recall that we were contacted by NO_COLOR folks to be\n>> an early supporter of their cause to break the chicken-and-egg\n>> problem they were hagving, and (unhelpfully) answered with \"sure,\n>> when we see enough people support it---otherwise we'd end up having\n>> to keep essentially a dead code that supports a convention that is\n>> not all that useful\".\n>\n> Yeah, I seem to recall you were somewhat negative on it at the time, but\n> I do personally find it useful, and someone on Twitter reminded me of\n> it just today.\n>\n>> I wonderr if it is just a matter of hooking into want_color(), like this?\n>> \n>> color.c | 7 ++++++-\n>> 1 file changed, 6 insertions(+), 1 deletion(-)\n>> \n>> diff --git c/color.c w/color.c\n>> index 64f52a4f93..2516ef7275 100644\n>> --- c/color.c\n>> +++ w/color.c\n>> @@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)\n>> \t * we always write the same value, but it's still wrong. This function\n>> \t * is listed in .tsan-suppressions for the time being.\n>> \t */\n>> -\n>> +\tstatic int no_color = -1;\n>> \tstatic int want_auto[3] = { -1, -1, -1 };\n>> \n>> \tif (fd < 1 || fd >= ARRAY_SIZE(want_auto))\n>> \t\tBUG(\"file descriptor out of range: %d\", fd);\n>> \n>> +\tif (no_color < 0)\n>> +\t\tno_color = !!getenv(\"NO_COLOR\");\n>> +\tif (no_color)\n>> +\t\treturn 0;\n>> +\n>> \tif (var < 0)\n>> \t\tvar = git_use_color_default;\n>> \n>\n> Yeah, that will probably do it. I hadn't looked at it, but I assumed it\n> would be pretty easy, and it looks like it is.\n\nActually I doubt it satisfies the FAQ #2 of no-color.org; we\nprobably would need to go one level lower, like the original\nproposal from 2018 did:\n\ncf. https://lore.kernel.org/git/87efl3emlm.fsf@vuxu.org/\n\n"},{"id":"424925","messageId":"87lf8bqdv0.fsf@evledraar.gmail.com","threadId":"55714","inReplyTo":"xmqq1ra3z23n.fsf@gitster.g","subject":"Re: [PATCH] help: colorize man pages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-19T08:41:44Z","receivedAt":"2021-05-19T09:20:24Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, May 19 2021, Junio C Hamano wrote:\n\n> \"brian m. carlson\" writes:\n>\n>> On 2021-05-19 at 01:08:54, Junio C Hamano wrote:\n>>> \"brian m. carlson\" writes:\n>>> \n>>> > In general, this is made worse because Git doesn't honor the unofficial\n>>> > but widely supported NO_COLOR[0], so reading the documentation is\n>>> > obligatory.\n>>> \n>>> I vaguely recall that we were contacted by NO_COLOR folks to be\n>>> an early supporter of their cause to break the chicken-and-egg\n>>> problem they were hagving, and (unhelpfully) answered with \"sure,\n>>> when we see enough people support it---otherwise we'd end up having\n>>> to keep essentially a dead code that supports a convention that is\n>>> not all that useful\".\n>>\n>> Yeah, I seem to recall you were somewhat negative on it at the time, but\n>> I do personally find it useful, and someone on Twitter reminded me of\n>> it just today.\n>>\n>>> I wonderr if it is just a matter of hooking into want_color(), like this?\n>>> \n>>> color.c | 7 ++++++-\n>>> 1 file changed, 6 insertions(+), 1 deletion(-)\n>>> \n>>> diff --git c/color.c w/color.c\n>>> index 64f52a4f93..2516ef7275 100644\n>>> --- c/color.c\n>>> +++ w/color.c\n>>> @@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)\n>>> \t * we always write the same value, but it's still wrong. This function\n>>> \t * is listed in .tsan-suppressions for the time being.\n>>> \t */\n>>> -\n>>> +\tstatic int no_color = -1;\n>>> \tstatic int want_auto[3] = { -1, -1, -1 };\n>>> \n>>> \tif (fd < 1 || fd >= ARRAY_SIZE(want_auto))\n>>> \t\tBUG(\"file descriptor out of range: %d\", fd);\n>>> \n>>> +\tif (no_color < 0)\n>>> +\t\tno_color = !!getenv(\"NO_COLOR\");\n>>> +\tif (no_color)\n>>> +\t\treturn 0;\n>>> +\n>>> \tif (var < 0)\n>>> \t\tvar = git_use_color_default;\n>>> \n>>\n>> Yeah, that will probably do it. I hadn't looked at it, but I assumed it\n>> would be pretty easy, and it looks like it is.\n>\n> Actually I doubt it satisfies the FAQ #2 of no-color.org; we\n> probably would need to go one level lower, like the original\n> proposal from 2018 did:\n>\n> cf. https://lore.kernel.org/git/87efl3emlm.fsf@vuxu.org/\n\n[CC'd the author of that proposal]\n\nIt also doesn't seem to me to satisfy their FAQ point #1, i.e. users who\nactually want no color at all can just set TERM=dumb, and we support\nthat. The proposed patch is the same as having TERM=dumb set.\n\nThis NO_COLOR=1 actually means something like \"I do support colors, so\nshow them if it's important, but don't color things willy-nilly\".\n\nI'm not sure if it matters for git, the FAQ point isn't really clear on\nwhat the distinction is exactly. Users who want to use color for say CLI\nemacs/vim/screen/tmux \"status\" bars, but don't want any \"normal\" CLI\nprogram to emit them?\n\nBut if we gained such a \"status\" bar feature the proposed 2018 patch\nwould be actively going against what NO_COLOR users want, since it's our\nequivalent of TERM=dumb, not whatever NO_COLOR=1 is supposed to mean. Or\nmaybe we already have that, I would think that \"git add -i\"'s UI would\ncount.\n\nIt seems like it really should have been named MOSTLY_NOT_COLOR=1 or\nONLY_COLOR_NCURSES_LIKE_UIS=1 if I'm understanding that FAQ item\ncorrectly.\n\nSo it would be incorrect to map it to either color.ui=never or\ncolor.ui=always (as \"auto\" will implicitly do). We'd need a new knob to\ncontrol the granularity of coloring, something like\ncolor.ui=conservative.\n\nI wasn't against NO_COLOR before, but after writing the above I think I\nam. I initially assumed that it was some redundant and more \"friendly\"\nway of setting TERM=dumb, but rather it's some entirely subjective way\nfor every program to decide if their UI elements are \"text-editor\"-like\nor \"status bar\"-like enough to warrant coloring.\n\nThat's \"against\" in the sense that if git supported it I wouldn't care\nmuch, and wouldn't oppose a patch to implement it.\n\nBut it seems to me to just introduce even more confusion to the *nix\ncoloring landscape. For what it's apparently trying to accomplish I\nthink it would be a much better thing to:\n\n 1. Have terminals/startup rc'd etc. set a TERM_ACTUAL=\n before setting TERM=dumb. This is something POSIX et al could\n eventually standardize, i.e. \"TERM=dumb\" for now, but actually I\n support \"TERM=xyz\".\n\n 2. Have some \"color_this\" shell function/alias/wrapper to start things\n like your editor, which would just be a one-line wrapper to start\n that program with TERM=$TERM_ACTUAL, or those programs would learn\n to look at TERM_ACTUAL.\n\nThe user would thus get color almost nowhere in \"normal\" programs like\n\"git status\" or \"ls\", but would get them in emacs, vim, screet, tmux,\nhtop or whatever other \"big\" terminal UI they run.\n\nI.e. the whole point seems to be to support the use-case of wanting\ncolor almost nowhere except a very small whitelist of programs, but\ntrying to accomplish it with NO_COLOR means that hundreds/thousands of\nprograms need to support it, as opposed to the much smaller list of\neditors/terminal multiplexers etc.\n\nEach of those programs then need to subjectively decide if their UI\nelements are \"such as [...] a status bar\". If they get it wrong the user\nis back to inovking them with TERM=dumb anyway.\n"},{"id":"424929","messageId":"87im3fqci9.fsf@evledraar.gmail.com","threadId":"55714","inReplyTo":"YKRSlFcFAcHcR3uY@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-19T09:26:12Z","receivedAt":"2021-05-19T09:49:44Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, May 18 2021, brian m. carlson wrote:\n\n> [[PGP Signed Part:Undecided]]\n> On 2021-05-18 at 03:22:37, Felipe Contreras wrote:\n>> brian m. carlson wrote:\n>> > I think we should let the user decide whether they want to set this\n>> > feature themselves instead of setting it for them. For example, I have\n>> > specific colors set up with these environment variables, and I'd like\n>> > Git to honor them without having to configure Git independently of less.\n>> > I expect other users will expect Git's rendering of the manual pages to\n>> > work like other instances of man(1) on their system as well.\n>> \n>> It does respect them.\n>> \n>> This would render the man page with the color specified in the\n>> environment, not the default of git.\n>> \n>> LESS_TERMCAP_md=$'\\e[1;33m' LESS_TERMCAP_me=$'\\e[m' git help git\n>\n> It still doesn't work like other instances of man(1) on the system.\n> While you claimed that \"that's a preference others don't share\", I'm\n> pretty certain that I'm not the only person who feels this way.\n>\n> There's a big difference between Git coloring a Git UI, like a diff, and\n> Git coloring a separate program that already has sensible, standard\n> defaults. A user who has not configured any color settings would\n> probably not want Git to render manual pages one way, cargo to render\n> manual pages a second way, and still other programs to render manual\n> pages in other, incompatible ways. We need to consider not only the\n> impact that our decisions have in a vacuum, but what results similar\n> decisions from other projects would produce in the software ecosystem as\n> a whole.\n>\n> Would you consider various projects coloring their respective manual\n> pages differently to be a desirable state of affairs?\n\nI think it's an important distinction that we're not coloring any manual\npages, it's a question of whether we invoke \"man\" invoked by \"git help\n\" with the exact same paramaters/options a user would get with\n\"man git-\".\n\nRight now our documentation seems to suggest that we won't do any such\nmagic, but you can also set man.viewer to e.g. invoke a web browser or\nsomething instead of man(1).\n\nI don't think it's confusing in that context if we learn to do some \"man\nwith fancy on top\" in this mode.\n\n>> > Additionally, using colors poses accessibility problems. I know someone\n>> > who, due to his colorblindness, finds terminal colors distracting and\n>> > hard to read, and prefers not to use them at all.\n>> \n>> git -c color.ui=never help git\n>\n> Yes, but unfortunately, since you've colored the manual pages, they may\n> be hard to read for the user who needs to read them to learn about your\n> configuration. This is great for you and me, who are already very\n> familiar with Git and know how to do that without looking, but not great\n> for the novice colorblind user.\n\nIs the objection here against the use of color, or that we e.g. replace\ngrey bold underline with blue bold, as opposed to blue bold underline?\n\nI'm not running the patch in this thread currently, but I'm running with\nFelipe's earlier man alias noted in the other thread. So I see how\nlosing the underline would be confusing.\n\nBut if colors only add, but don't substract information by default\nthat's not an issue for the color blind, correct? Or at least that's\nbeen my understanding in helping color blind user in the past (and not\nbeing color blind myself).\n\nI.e. issue isn't colors per-se, or even a UI that would make an\negregious of coloring, rather it's if that UI uses color as a\n*replacement* for showing the same information in another way.\n\nI may be entirely wrong, but I think it's a point worth bringing up to\nfind some solution here, i.e. if we find that not losing the underline\n(but adding color) is a solution acceptable to everyone.\n\n> For similar reasons, colorizing help output in general is unhelpful\n> because users cannot find the options to disable it.\n\nThis seems to just be a re-hash of the old argument that git does\ncoloring by default, not specifically about \"git help \".\n\nI think there's good arguments for/against that, but I do think that\nultimately it was a good choice, and programs such as hg(1) seemed to\nsince have moved to git's more aggressive \"color by default\" stance.\n\n> In general, this is made worse because Git doesn't honor the unofficial\n> but widely supported NO_COLOR[0], so reading the documentation is\n> obligatory.\n\nI replied about NO_COLOR in\n<87lf8bqdv0.fsf@evledraar.gmail.com>.\n\nRegardless of whether or not that's a good idea I don't see how it's\nrelevant here. We'd support TERM=dumb, which is *the* standard way to\ntweak this for all programs.\n\n>> > Even users who want to use them might find some colors to be too\n>> > similar, and this patch doesn't permit them to be configured.\n>> \n>> Yes it does:\n>> \n>> LESS_TERMCAP_md=$'\\e[01;38;5;33m' git help git\n>\n> I should clarify that the patch doesn't permit them to be configured\n> using the normal Git mechanisms. For example, unless the user sets the\n> environment variables, which take effect globally, they're stuck with\n> the colors that we've chosen here. Yes, they can specify a single\n> environment variable before the command, but practically nobody will do\n> that.\n>\n> It's my argument that the user doesn't want Git manual pages to be\n> colored differently than other manual pages on the system, but if you\n> believe differently, then we should allow the user to configure the\n> colors that are used in the Git-specific context using Git standard\n> mechanisms.\n\nI'm in vehement agreement about this. If we do invoke \"man\" differently\nbased on how we'd do coloring for any other git program we invoke, we\nshould of course be respecting the same configuration\nmechanisms. I.e. it should respect color.ui=auto etc., you shouldn't\nneed to set LESS_TERMCAP_md or whatever.\n\n>> > In my particular case, despite having normal color vision, because I use\n>> > a transparent terminal which often results in a grey background, I find\n>> > the standard terminal red to be difficult to read, and so this patch\n>> > would result in a significant decrease in the readability of the manual\n>> > pages for me.\n>> \n>> If you have LESS_TERMCAP_md set in your environment, it won't.\n>\n> The problem is, I don't always. I am on call for a set of hundreds of\n> servers, only one of which has my shell configuration set up, so\n> defaults here matter. Moreover, because there are many novice users of\n> Git, we should consider that for a decent number of users, they\n> literally won't know where to look in our documentation to make\n> changes, and therefore the defaults matter for them, too.\n\nThese servers don't have TERM in their list of AcceptEnv variables, or\nequivalent?\n\nIn any case, I think for these defaults we need to be considering the\nvast majority of users, who are mostly interfacing with one or two\ncomputers in their use of \"git\", and who are running some modern OS that\nsupports terminal coloring, which is why color.ui=auto became the\ndefault (to some objections at the time, but I think those have gotten\nless prominent as time marched on).\n"},{"id":"424932","messageId":"YKTkIgdJgBomzieH@coredump.intra.peff.net","threadId":"55714","inReplyTo":"87im3fqci9.fsf@evledraar.gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-19T10:10:42Z","receivedAt":"2021-05-19T10:10:45Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 19, 2021 at 11:26:12AM +0200, Ævar Arnfjörð Bjarmason wrote:\n\n> > There's a big difference between Git coloring a Git UI, like a diff, and\n> > Git coloring a separate program that already has sensible, standard\n> > defaults. A user who has not configured any color settings would\n> > probably not want Git to render manual pages one way, cargo to render\n> > manual pages a second way, and still other programs to render manual\n> > pages in other, incompatible ways. We need to consider not only the\n> > impact that our decisions have in a vacuum, but what results similar\n> > decisions from other projects would produce in the software ecosystem as\n> > a whole.\n> >\n> > Would you consider various projects coloring their respective manual\n> > pages differently to be a desirable state of affairs?\n> \n> I think it's an important distinction that we're not coloring any manual\n> pages, it's a question of whether we invoke \"man\" invoked by \"git help\n> \" with the exact same paramaters/options a user would get with\n> \"man git-\".\n> \n> Right now our documentation seems to suggest that we won't do any such\n> magic, but you can also set man.viewer to e.g. invoke a web browser or\n> something instead of man(1).\n> \n> I don't think it's confusing in that context if we learn to do some \"man\n> with fancy on top\" in this mode.\n\nI agree that we could explain it as \"man with fancy on top\". But it\nmakes me wonder: why is this Git's responsibility to do the fancy at\nall?\n\nI.e., if you want colorized manpages, why don't you configure man to do\nso? Sure, it's a bit of a pain to do so since it involves setting a\nbunch of obscure environment variables. But if that's what you want,\nwouldn't you want it for all manpages, whether you ran \"git help log\" or\n\"man git-log\" or \"man ls\"?\n\nThis seems like a \"man\" feature and not a \"git\" feature. And arguably\nsome of it is really a \"less\" feature (it is trying to set \"standout\"\nmode for its prompt, so configuring \"so\" and \"se\" termcap entries is\njust reinterpreting that. If you like, wouldn't you want it on for all\n\"less\" invocations?).\n\n-Peff\n"},{"id":"424934","messageId":"60a4e799ce22e_86a8208b7@natae.notmuch","threadId":"55714","inReplyTo":"YKRSlFcFAcHcR3uY@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-19T10:25:29Z","receivedAt":"2021-05-19T10:25:36Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-18 at 03:22:37, Felipe Contreras wrote:\n> > brian m. carlson wrote:\n> > > I think we should let the user decide whether they want to set this\n> > > feature themselves instead of setting it for them. For example, I have\n> > > specific colors set up with these environment variables, and I'd like\n> > > Git to honor them without having to configure Git independently of less.\n> > > I expect other users will expect Git's rendering of the manual pages to\n> > > work like other instances of man(1) on their system as well.\n> > \n> > It does respect them.\n> > \n> > This would render the man page with the color specified in the\n> > environment, not the default of git.\n> > \n> > LESS_TERMCAP_md=$'\\e[1;33m' LESS_TERMCAP_me=$'\\e[m' git help git\n> \n> It still doesn't work like other instances of man(1) on the system.\n> While you claimed that \"that's a preference others don't share\", I'm\n> pretty certain that I'm not the only person who feels this way.\n\nTwo people feeling in a certain way is not an argument against a feature\nthat could potentially benefit millions of people.\n\n> There's a big difference between Git coloring a Git UI, like a diff, and\n> Git coloring a separate program that already has sensible, standard\n> defaults.\n\nWould you be happier if I implement an entirely new library to render\nasciidoc documentation in a pretty way and make `git help` link to that?\n\nThat way we wouldn't be using \"a separate program\".\n\n> A user who has not configured any color settings would\n> probably not want Git to render manual pages one way, cargo to render\n> manual pages a second way, and still other programs to render manual\n> pages in other, incompatible ways.\n\nThat is one opinion. Again, not shared by everyone.\n\n> Would you consider various projects coloring their respective manual\n> pages differently to be a desirable state of affairs?\n\nThat is irrelevant, because we are not talking about `man git`, we are\ntalking about `git help git`, which can render help in a variety of\nways.\n\nYou can do for example `git -c man.viewer=woman help git`, and the\nresult would be *completely* different from what the user sees in `man\ngit`.\n\nA different thing is different.\n\nWould you be happier if we enable this with `man.viewer=mancolor`?\n\n> > > Additionally, using colors poses accessibility problems. I know someone\n> > > who, due to his colorblindness, finds terminal colors distracting and\n> > > hard to read, and prefers not to use them at all.\n> > \n> > git -c color.ui=never help git\n> \n> Yes, but unfortunately, since you've colored the manual pages, they may\n> be hard to read for the user who needs to read them to learn about your\n> configuration.\n\nman git\n\n> > > Even users who want to use them might find some colors to be too\n> > > similar, and this patch doesn't permit them to be configured.\n> > \n> > Yes it does:\n> > \n> > LESS_TERMCAP_md=$'\\e[01;38;5;33m' git help git\n> \n> I should clarify that the patch doesn't permit them to be configured\n> using the normal Git mechanisms. For example, unless the user sets the\n> environment variables, which take effect globally, they're stuck with\n> the colors that we've chosen here. Yes, they can specify a single\n> environment variable before the command, but practically nobody will do\n> that.\n\nIf you don't like the colors they can disable them.\n\nThey lose absolutely nothing from the state of git 2.31.\n\n> It's my argument that the user doesn't want Git manual pages to be\n> colored differently than other manual pages on the system,\n\n/usr/share/man/man1/git.1.gz is not changed.\n\n> > > In my particular case, despite having normal color vision, because I use\n> > > a transparent terminal which often results in a grey background, I find\n> > > the standard terminal red to be difficult to read, and so this patch\n> > > would result in a significant decrease in the readability of the manual\n> > > pages for me.\n> > \n> > If you have LESS_TERMCAP_md set in your environment, it won't.\n> \n> The problem is, I don't always. I am on call for a set of hundreds of\n> servers, only one of which has my shell configuration set up, so\n> defaults here matter.\n\nSurely you can live typing `man $x` instead of `git help $x` for a bit.\n\n> Moreover, because there are many novice users of\n> Git, we should consider that for a decent number of users, they\n> literally won't know where to look in our documentation to make\n> changes, and therefore the defaults matter for them, too.\n\nAnd we are considering them.\n\nBut the defaults are for the majority.\n\n-- \nFelipe Contreras\n"},{"id":"424935","messageId":"60a4ea28a3807_86a8208d5@natae.notmuch","threadId":"55714","inReplyTo":"87lf8bqdv0.fsf@evledraar.gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-19T10:36:24Z","receivedAt":"2021-05-19T10:36:37Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> This NO_COLOR=1 actually means something like \"I do support colors, so\n> show them if it's important, but don't color things willy-nilly\".\n\nIn my subjective opinion most of git uses color sensibly, so we kind of\nalready support NO_COLOR (turn it on, and you'd get sensible colors).\n\nExcept, my patch to colorize man pages can be considered to be coloring\nthings willy-nilly.\n\nSo perhaps that's the only instance where we should consider caring\nabout that.\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424940","messageId":"60a4f4312264f_86a82089b@natae.notmuch","threadId":"55714","inReplyTo":"87im3fqci9.fsf@evledraar.gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-19T11:19:13Z","receivedAt":"2021-05-19T11:19:18Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, May 18 2021, brian m. carlson wrote:\n> \n> > [[PGP Signed Part:Undecided]]\n> > On 2021-05-18 at 03:22:37, Felipe Contreras wrote:\n> >> brian m. carlson wrote:\n> >> > I think we should let the user decide whether they want to set this\n> >> > feature themselves instead of setting it for them. For example, I have\n> >> > specific colors set up with these environment variables, and I'd like\n> >> > Git to honor them without having to configure Git independently of less.\n> >> > I expect other users will expect Git's rendering of the manual pages to\n> >> > work like other instances of man(1) on their system as well.\n> >> \n> >> It does respect them.\n> >> \n> >> This would render the man page with the color specified in the\n> >> environment, not the default of git.\n> >> \n> >> LESS_TERMCAP_md=$'\\e[1;33m' LESS_TERMCAP_me=$'\\e[m' git help git\n> >\n> > It still doesn't work like other instances of man(1) on the system.\n> > While you claimed that \"that's a preference others don't share\", I'm\n> > pretty certain that I'm not the only person who feels this way.\n> >\n> > There's a big difference between Git coloring a Git UI, like a diff, and\n> > Git coloring a separate program that already has sensible, standard\n> > defaults. A user who has not configured any color settings would\n> > probably not want Git to render manual pages one way, cargo to render\n> > manual pages a second way, and still other programs to render manual\n> > pages in other, incompatible ways. We need to consider not only the\n> > impact that our decisions have in a vacuum, but what results similar\n> > decisions from other projects would produce in the software ecosystem as\n> > a whole.\n> >\n> > Would you consider various projects coloring their respective manual\n> > pages differently to be a desirable state of affairs?\n> \n> I think it's an important distinction that we're not coloring any manual\n> pages,\n\nBut we *are* coloring man pages. The docbook stylesheets format links as\nblue.\n\nTry this:\n\n GROFF_SGR=1 man git\n\n> Right now our documentation seems to suggest that we won't do any such\n> magic, but you can also set man.viewer to e.g. invoke a web browser or\n> something instead of man(1).\n> \n> I don't think it's confusing in that context if we learn to do some \"man\n> with fancy on top\" in this mode.\n\nBut man already does fancy stuff.\n\nYou can open a browser:\n\n man -Hchromium git\n\nYou display some shitty X viewer:\n\n man -X git\n\nYou can send the man page to a printer, or generate a DVI file.\n\nThe pager mode in man is also just one of many modes.\n\nI think most people have not read man man.\n\n> I'm not running the patch in this thread currently, but I'm running with\n> Felipe's earlier man alias noted in the other thread. So I see how\n> losing the underline would be confusing.\n\nBut in my patch you don't lose the underline.\n\nThe function version I sent was an updated version of something I've\nbeen using for a long time. But I did more effort in the version for\nwide consumption, and the underline is preserved.\n\nThis is the equivalent of my latest patch:\n\n man () {\n GROFF_NO_SGR=1 \\\n LESS_TERMCAP_md=$'\\e[1;31m' \\\n LESS_TERMCAP_me=$'\\e[m' \\\n LESS_TERMCAP_us=$'\\e[1;34m\\e[4m' \\\n LESS_TERMCAP_ue=$'\\e[m' \\\n LESS_TERMCAP_so=$'\\e[1;35m\\e[7m' \\\n LESS_TERMCAP_se=$'\\e[m' \\\n command man \"$@\"\n }\n\n> I think there's good arguments for/against that, but I do think that\n> ultimately it was a good choice, and programs such as hg(1) seemed to\n> since have moved to git's more aggressive \"color by default\" stance.\n\nI would say a lot of programs have been doing that, and I like it. The\nlast one I discovered is jq.\n\n> > I should clarify that the patch doesn't permit them to be configured\n> > using the normal Git mechanisms. For example, unless the user sets the\n> > environment variables, which take effect globally, they're stuck with\n> > the colors that we've chosen here. Yes, they can specify a single\n> > environment variable before the command, but practically nobody will do\n> > that.\n> >\n> > It's my argument that the user doesn't want Git manual pages to be\n> > colored differently than other manual pages on the system, but if you\n> > believe differently, then we should allow the user to configure the\n> > colors that are used in the Git-specific context using Git standard\n> > mechanisms.\n> \n> I'm in vehement agreement about this. If we do invoke \"man\" differently\n> based on how we'd do coloring for any other git program we invoke, we\n> should of course be respecting the same configuration\n> mechanisms. I.e. it should respect color.ui=auto etc., you shouldn't\n> need to set LESS_TERMCAP_md or whatever.\n\nYes, but good software is developed in stages.\n\nYou shouldn't expect a first patch to provide all the functionality in\nthe world. Not only does it take longer, increase the review burden, and\ngenerate longer disucssions, but it increases the probability of the\nfeature never been merged.\n\nPlus increases the probability of bugs bein introduced.\n\nMore features can be added later.\n\nWhat is important is that users don't lose anything from what they have\nnow.\n\nAnd unconfigurable colors is better than what they have now... Nothing.\n\n> In any case, I think for these defaults we need to be considering the\n> vast majority of users, who are mostly interfacing with one or two\n> computers in their use of \"git\", and who are running some modern OS that\n> supports terminal coloring, which is why color.ui=auto became the\n> default (to some objections at the time, but I think those have gotten\n> less prominent as time marched on).\n\nExactly.\n\nMoreover, if colors are really that bad, then users will complain (I bet\nthey won't), and then we can switch this off by default.\n\nEasy.\n\n-- \nFelipe Contreras"},{"id":"424942","messageId":"60a4fa4dc7701_86a820896@natae.notmuch","threadId":"55714","inReplyTo":"YKTkIgdJgBomzieH@coredump.intra.peff.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-19T11:45:17Z","receivedAt":"2021-05-19T11:45:25Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Wed, May 19, 2021 at 11:26:12AM +0200, Ævar Arnfjörð Bjarmason wrote:\n> \n> > > There's a big difference between Git coloring a Git UI, like a diff, and\n> > > Git coloring a separate program that already has sensible, standard\n> > > defaults. A user who has not configured any color settings would\n> > > probably not want Git to render manual pages one way, cargo to render\n> > > manual pages a second way, and still other programs to render manual\n> > > pages in other, incompatible ways. We need to consider not only the\n> > > impact that our decisions have in a vacuum, but what results similar\n> > > decisions from other projects would produce in the software ecosystem as\n> > > a whole.\n> > >\n> > > Would you consider various projects coloring their respective manual\n> > > pages differently to be a desirable state of affairs?\n> > \n> > I think it's an important distinction that we're not coloring any manual\n> > pages, it's a question of whether we invoke \"man\" invoked by \"git help\n> > \" with the exact same paramaters/options a user would get with\n> > \"man git-\".\n> > \n> > Right now our documentation seems to suggest that we won't do any such\n> > magic, but you can also set man.viewer to e.g. invoke a web browser or\n> > something instead of man(1).\n> > \n> > I don't think it's confusing in that context if we learn to do some \"man\n> > with fancy on top\" in this mode.\n> \n> I agree that we could explain it as \"man with fancy on top\". But it\n> makes me wonder: why is this Git's responsibility to do the fancy at\n> all?\n\nIt is not.\n\nJust like it is not git's responsibility to display diffs in color.\n\nBut it's a nice thing to do.\n\n> I.e., if you want colorized manpages, why don't you configure man to do\n> so?\n\nBecause this has nothing to do with man.\n\nIn the default mode man just takes the output of groff, and passes it to\na pager. That's it.\n\nIt doesn't know anything of colors. That's between groff and less.\n\n> Sure, it's a bit of a pain to do so since it involves setting a\n> bunch of obscure environment variables.\n\nThe environment variables are for less, not man.\n\nIf you export those variables into your environment, you could\npotentially mess up the output of some programs when viewed through\nless.\n\nThat's why in my tip I set the variables only for man, inside a man\nfunction wrap: man () { FOO=1 command man \"$@\"; }\n\n> But if that's what you want, wouldn't you want it for all manpages,\n> whether you ran \"git help log\" or \"man git-log\" or \"man ls\"?\n\nHow? (without messing up the environment for other programs that use a\npager)\n\n> This seems like a \"man\" feature and not a \"git\" feature.\n\nman does not care. It can do many things, dumping data onto a pager is\njust one of them.\n\nWhere does LESS_TERMCAP_* affect `man -Hchromium git`? For more read man man.\n\n> And arguably some of it is really a \"less\" feature\n\nIt's *all* a less feature.\n\n> (it is trying to set \"standout\" mode for its prompt, so configuring\n> \"so\" and \"se\" termcap entries is just reinterpreting that. If you\n> like, wouldn't you want it on for all \"less\" invocations?).\n\nI don't.\n\nRendering things correctly on a terminal is tricky enough as it is, I\nwould like to hedge such kinds of changes inside a controlled\nenvironment.\n\nWhich is exactly what my patch does.\n\n-- \nFelipe Contreras"},{"id":"424955","messageId":"60a502be5eaa5_17b88208cc@natae.notmuch","threadId":"55714","inReplyTo":"60a4f4312264f_86a82089b@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-19T12:21:18Z","receivedAt":"2021-05-19T12:21:25Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Felipe Contreras wrote:\n> This is the equivalent of my latest patch:\n> \n> man () {\n> GROFF_NO_SGR=1 \\\n> LESS_TERMCAP_md=$'\\e[1;31m' \\\n> LESS_TERMCAP_me=$'\\e[m' \\\n> LESS_TERMCAP_us=$'\\e[1;34m\\e[4m' \\\n> LESS_TERMCAP_ue=$'\\e[m' \\\n> LESS_TERMCAP_so=$'\\e[1;35m\\e[7m' \\\n> LESS_TERMCAP_se=$'\\e[m' \\\n> command man \"$@\"\n> }\n\nWait a second...\n\n MANPAGER=\"less -Dd+r -Du+b -Ds+m\" GROFF_NO_SGR=1 command man \"$@\"\n\nReading man pages pays off ;)\n\n-- \nFelipe Contreras\n"},{"id":"425014","messageId":"YKXBdQ36MYz2YG8s@camp.crustytoothpaste.net","threadId":"55714","inReplyTo":"87im3fqci9.fsf@evledraar.gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-20T01:55:01Z","receivedAt":"2021-05-20T01:56:57Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-19 at 09:26:12, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, May 18 2021, brian m. carlson wrote:\n> \n> > Would you consider various projects coloring their respective manual\n> > pages differently to be a desirable state of affairs?\n> \n> I think it's an important distinction that we're not coloring any manual\n> pages, it's a question of whether we invoke \"man\" invoked by \"git help\n> \" with the exact same paramaters/options a user would get with\n> \"man git-\".\n\nYes. I would expect that if the man option is chosen, then we invoke\nman without modification. If I wanted different options, I would have\nspecified a custom viewer with different options. For example, I would\nbe equally annoyed if Git decided to use a completely different pager\nfor man output than I would normally use to make it \"fancy\".\n\nThe documentation says, \"use the man program as usual\". \"As usual\"\nimplies the way the user would invoke it.\n\nIf we want to add an option for special coloring or modifications, then\nwe should add an option --fancy-man, where we do something other than\ninvoking man as normal.\n\nIf we were doing our own man-like documentation and not specifically\nusing man, then I would agree that we'd be free to color it without\nrelying on the user's expectations about how man works otherwise\n(although other objections still apply).\n\n> I don't think it's confusing in that context if we learn to do some \"man\n> with fancy on top\" in this mode.\n\nI think it's confusing if Git does fancy one way, and other projects\nwhich invoke man like cargo do it another way. It's pretty obvious that\n\"git help commit\" and \"cargo help build\" both are intended to invoke man\nwhen used in the normal way.\n\n> >> > Additionally, using colors poses accessibility problems. I know someone\n> >> > who, due to his colorblindness, finds terminal colors distracting and\n> >> > hard to read, and prefers not to use them at all.\n> >> \n> >> git -c color.ui=never help git\n> >\n> > Yes, but unfortunately, since you've colored the manual pages, they may\n> > be hard to read for the user who needs to read them to learn about your\n> > configuration. This is great for you and me, who are already very\n> > familiar with Git and know how to do that without looking, but not great\n> > for the novice colorblind user.\n> \n> Is the objection here against the use of color, or that we e.g. replace\n> grey bold underline with blue bold, as opposed to blue bold underline?\n> \n> I'm not running the patch in this thread currently, but I'm running with\n> Felipe's earlier man alias noted in the other thread. So I see how\n> losing the underline would be confusing.\n> \n> But if colors only add, but don't substract information by default\n> that's not an issue for the color blind, correct? Or at least that's\n> been my understanding in helping color blind user in the past (and not\n> being color blind myself).\n\nThe problem becomes if the color is indistinguishable from other\nelements. For example, I have a friend who has deuteranopia who sees\ngreen as very similar to grey. Therefore, an environment where a text\nis green and the background is grey, without significant differences in\nlightness, will likely be illegible for him.\n\nIt is _also_ a problem if we have two colors with sufficient contrast\nbetween the foreground and background but those colors look the same and\nthere is no other distinguishing factor.\n\nSo, yes, if the colors only add information and they can otherwise be\ndistinguished, then it's fine. However, we're not setting the\nbackground here, only the foreground, and we don't know how the user has\nconfigured their terminal background.\n\nIn my particular case, I have a semi-transparent background, which,\nbecause my terminal is often in front of a web browser and many web\npages have light backgrounds is often a medium grey, so a dark red is\nillegible here because of poor contrast. That is true regardless of the\nfact that I don't have colorblindness; people with colorblindness just\nhave more colors (depending on the type) where contrast is poor.\n\n> I.e. issue isn't colors per-se, or even a UI that would make an\n> egregious of coloring, rather it's if that UI uses color as a\n> *replacement* for showing the same information in another way.\n\nTerminals with colored foregrounds color text, which is the relevant\npart, because that's the part people need to read. I'm less concerned\nabout us losing the bold or italic nature of text, since that can\nusually be ignored without much loss of information. For example, if a\nperson viewed all roman, bold, and italic text as uniform but legible,\nI'm not worried.\n\nIt is fine for accessibility reasons if we color both the foreground and\nthe background and we ensure they have reasonable distinctiveness.\nHowever, that also results in us breaking the transparent nature of\nterminals people have configured that way.\n\n> > For similar reasons, colorizing help output in general is unhelpful\n> > because users cannot find the options to disable it.\n> \n> This seems to just be a re-hash of the old argument that git does\n> coloring by default, not specifically about \"git help \".\n> \n> I think there's good arguments for/against that, but I do think that\n> ultimately it was a good choice, and programs such as hg(1) seemed to\n> since have moved to git's more aggressive \"color by default\" stance.\n\nNo, I don't think that's the same thing. I like that Git does coloring\nby default. I use coloring extensively in Git, and especially the zebra\ncoloring of diffs. I also use coloring in my prompt and my editor, and\nI like all of that. I think all of this adds a lot of value, and I like\nthat Git allows a great deal of customization over this.\n\nWhat I don't like is when a program colors text in a certain way, I\ncan't read it, and then I can't read the help output or documentation to\nturn it off. I am specifically arguing against coloring our\ndocumentation and help output because it leaves users with little\nrecourse to fix the problem.\n\n> > In general, this is made worse because Git doesn't honor the unofficial\n> > but widely supported NO_COLOR[0], so reading the documentation is\n> > obligatory.\n> \n> I replied about NO_COLOR in\n> <87lf8bqdv0.fsf@evledraar.gmail.com>.\n> \n> Regardless of whether or not that's a good idea I don't see how it's\n> relevant here. We'd support TERM=dumb, which is *the* standard way to\n> tweak this for all programs.\n\nTERM=dumb breaks all addressable cursor support, all use of bold and\nstandout functionality, and functionality like readline and editline.\nSetting TERM=dumb and then invoking man will result in an inability to\npage backwards, so that's not a suitable alternative; similarly, it\nbreaks any sort of interactive prompt (e.g., the shell).\n\n> > The problem is, I don't always. I am on call for a set of hundreds of\n> > servers, only one of which has my shell configuration set up, so\n> > defaults here matter. Moreover, because there are many novice users of\n> > Git, we should consider that for a decent number of users, they\n> > literally won't know where to look in our documentation to make\n> > changes, and therefore the defaults matter for them, too.\n> \n> These servers don't have TERM in their list of AcceptEnv variables, or\n> equivalent?\n\nThey do support TERM. I can't set TERM=dumb because then basic prompt\nediting doesn't work.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"425019","messageId":"xmqq35uiw3bm.fsf@gitster.g","threadId":"55714","inReplyTo":"YKXBdQ36MYz2YG8s@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-20T02:23:41Z","receivedAt":"2021-05-20T02:24:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> The documentation says, \"use the man program as usual\". \"As usual\"\n> implies the way the user would invoke it.\n\nI guess what the documentation says matches what end users expect (I\nas an end user certainly do expect that \"git help -m foo\" is running\nthe familiar \"man\" command on something that is related to \"foo\").\n\nSo while making the \"less\" customization more discoverable and\neasily accessible would be a win for users, I have to agree that is\nout of scope of this project's mission.\n\nWe used to give helpful hints how to configure LESS environment\nvariable in a way that does not conflict with our use somewhere in\nthe doc. I think the hints how to configure these set of environment\nvariables for \"less\" users may belong to a similar place in the doc,\nif we wanted to do something, but going beyond that would probably\nbe more confusing and disorienting than helpful to our users (they'll\nstart wondering why \"git help\"'s output does not look like the\noutput from \"man ls\").\n\nThanks for discussing this topic.\n\n\n"},{"id":"425022","messageId":"60a5cd3ed5aaf_1e275208a0@natae.notmuch","threadId":"55714","inReplyTo":"YKXBdQ36MYz2YG8s@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-20T02:45:18Z","receivedAt":"2021-05-20T02:45:23Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-19 at 09:26:12, Ævar Arnfjörð Bjarmason wrote:\n> > \n> > On Tue, May 18 2021, brian m. carlson wrote:\n> > \n> > > Would you consider various projects coloring their respective manual\n> > > pages differently to be a desirable state of affairs?\n> > \n> > I think it's an important distinction that we're not coloring any manual\n> > pages, it's a question of whether we invoke \"man\" invoked by \"git help\n> > \" with the exact same paramaters/options a user would get with\n> > \"man git-\".\n> \n> Yes. I would expect that if the man option is chosen, then we invoke\n> man without modification.\n\nDo you also expect git to call diff without options?\n\n> The documentation says, \"use the man program as usual\". \"As usual\"\n> implies the way the user would invoke it.\n\nThe documentation can be updated.\n\n> > I don't think it's confusing in that context if we learn to do some \"man\n> > with fancy on top\" in this mode.\n\n> It's pretty obvious that \"git help commit\" and \"cargo help build\" both\n> are intended to invoke man when used in the normal way.\n\nAnd I don't.\n\nI expect the output `foo help $x` to be decided by foo.\n\nIf I do `python help len` and I get an error, that's fine.\n\n> > But if colors only add, but don't substract information by default\n> > that's not an issue for the color blind, correct? Or at least that's\n> > been my understanding in helping color blind user in the past (and not\n> > being color blind myself).\n> \n> The problem becomes if the color is indistinguishable from other\n> elements.\n\nIt is not indistiguishable; a blind person would be able to distinguish\nthem. As much as they can without the patch.\n\n> It is _also_ a problem if we have two colors with sufficient contrast\n> between the foreground and background but those colors look the same and\n> there is no other distinguishing factor.\n\nThere is another distinguising factor: they are *bold*, or _underlined_.\n\n> So, yes, if the colors only add information and they can otherwise be\n> distinguished, then it's fine.\n\nWe are setting *bold*, _underlined_, and REVERSE.\n\nExactly in the same way as they are set already.\n\n\nA truly colorblind person would see no difference at all.\n\n> What I don't like is when a program colors text in a certain way, I\n> can't read it, and then I can't read the help output or documentation to\n> turn it off.\n\nIf you can't read `man git`, that has absolutely nothing to do with this\npatch.\n\n> I am specifically arguing against coloring our documentation\n\nWe already already coloring our documentation.\n\n> and help output because it leaves users with little recourse to fix\n> the problem.\n\nman git.\n\n-- \nFelipe Contreras"},{"id":"425023","messageId":"60a5d20a4e134_1f37320860@natae.notmuch","threadId":"55714","inReplyTo":"xmqq35uiw3bm.fsf@gitster.g","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-20T03:05:46Z","receivedAt":"2021-05-20T03:05:50Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> \"brian m. carlson\" writes:\n> \n> > The documentation says, \"use the man program as usual\". \"As usual\"\n> > implies the way the user would invoke it.\n> \n> I guess what the documentation says matches what end users expect (I\n> as an end user certainly do expect that \"git help -m foo\" is running\n> the familiar \"man\" command on something that is related to \"foo\").\n\nDo you also expect that `git diff a b` runs something similar to\n`diff a b`?\n\n> So while making the \"less\" customization more discoverable and\n> easily accessible would be a win for users, I have to agree that is\n> out of scope of this project's mission.\n\nHow is enabling a configuration already present in `man` out of scope,\nbut running an *ENTIRELY* different program--such as konqueror or\nwoman--to view man pages is not?\n\n git help --man git\n\nDoesn't even necessarily run man *already*.\n\n-- \nFelipe Contreras\n"},{"id":"425026","messageId":"xmqqpmxmulqt.fsf@gitster.g","threadId":"55714","inReplyTo":"60a5d20a4e134_1f37320860@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-20T03:28:42Z","receivedAt":"2021-05-20T03:28:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> How is enabling a configuration already present in `man` out of scope,\n> but running an *ENTIRELY* different program--such as konqueror or\n> woman--to view man pages is not?\n>\n> git help --man git\n>\n> Doesn't even necessarily run man *already*.\n\nAs an end-user, I do not expect Git to run konqueror or woman with\nits own tweaks when it does so. And I do not see a reason why \"man\"\nshould be any different.\n\n"},{"id":"425028","messageId":"60a5dc0ab8e2c_2044120877@natae.notmuch","threadId":"55714","inReplyTo":"xmqqpmxmulqt.fsf@gitster.g","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-20T03:48:26Z","receivedAt":"2021-05-20T03:48:31Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Felipe Contreras writes:\n> \n> > How is enabling a configuration already present in `man` out of scope,\n> > but running an *ENTIRELY* different program--such as konqueror or\n> > woman--to view man pages is not?\n> >\n> > git help --man git\n> >\n> > Doesn't even necessarily run man *already*.\n> \n> As an end-user, I do not expect Git to run konqueror or woman with\n> its own tweaks when it does so. And I do not see a reason why \"man\"\n> should be any different.\n\nYou skipped the first question: \n\nDo you also expect that `git diff a b` runs something similar to\n`diff a b`?\n\n-- \nFelipe Contreras\n"},{"id":"425172","messageId":"YKcFrbuuJrWAxXgm@camp.crustytoothpaste.net","threadId":"55714","inReplyTo":"87lf8bqdv0.fsf@evledraar.gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-21T00:58:21Z","receivedAt":"2021-05-21T00:58:29Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-19 at 08:41:44, Ævar Arnfjörð Bjarmason wrote:\n> It also doesn't seem to me to satisfy their FAQ point #1, i.e. users who\n> actually want no color at all can just set TERM=dumb, and we support\n> that. The proposed patch is the same as having TERM=dumb set.\n> \n> This NO_COLOR=1 actually means something like \"I do support colors, so\n> show them if it's important, but don't color things willy-nilly\".\n\nI don't agree. The way I read it is that it means that if your program\nreceives colored input, it is not obligated to strip it out, but it is\nobligated not to add any. For example, if less supported NO_COLOR, then\nit would render color it received on stdin, but not color its status\nbars.\n\nFor Git, this means that we shouldn't add color, but if a user has\nstuffed some ANSI escape sequences in their formatting string, we'll\npass them through.\n\n> So it would be incorrect to map it to either color.ui=never or\n> color.ui=always (as \"auto\" will implicitly do). We'd need a new knob to\n> control the granularity of coloring, something like\n> color.ui=conservative.\n\nNo, I think in the context of Git it means, \"I don't want color.\"\n\n> I wasn't against NO_COLOR before, but after writing the above I think I\n> am. I initially assumed that it was some redundant and more \"friendly\"\n> way of setting TERM=dumb, but rather it's some entirely subjective way\n> for every program to decide if their UI elements are \"text-editor\"-like\n> or \"status bar\"-like enough to warrant coloring.\n\nTERM=dumb turns off having an addressable cursor. Git uses a pager for\na lot of output, so that's a completely undesirable way to indicate you\ndon't want color, since it makes scrolling backwards impossible (and may\neven disable the pager, but I haven't checked). For a text editor,\nTERM=dumb means you're stuck with ex or ed.\n\nNO_COLOR=1 says, \"I don't want color, but I have a fully functional\nterminal I would like to use, thank you.\"\n\nI should point out that I think you've misread the text about status\nbars. It says this:\n\n It is reasonable to configure certain software such as a text editor\n to use color or other ANSI attributes sparingly (such as the reverse\n attribute for a status bar) while still desiring that other software\n not add color unless configured to. It should be up to the user\n whether color is used, not the software author.\n\nIn other words, I think in this case, the user has opted to configure\ntheir editor as they like it and invoke it without NO_COLOR, but has\ninstructed other programs to not add color with NO_COLOR.\n\nNote also that the explanation specifically mentions the reverse\nattribute, which TERM=dumb will suppress.\n\n> That's \"against\" in the sense that if git supported it I wouldn't care\n> much, and wouldn't oppose a patch to implement it.\n\nI will probably send a patch to implement it, just not tonight.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"425226","messageId":"60a7f7427eab6_55039208ba@natae.notmuch","threadId":"55714","inReplyTo":"YKcFrbuuJrWAxXgm@camp.crustytoothpaste.net","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-21T18:09:06Z","receivedAt":"2021-05-21T18:09:20Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-19 at 08:41:44, Ævar Arnfjörð Bjarmason wrote:\n> > It also doesn't seem to me to satisfy their FAQ point #1, i.e. users who\n> > actually want no color at all can just set TERM=dumb, and we support\n> > that. The proposed patch is the same as having TERM=dumb set.\n> > \n> > This NO_COLOR=1 actually means something like \"I do support colors, so\n> > show them if it's important, but don't color things willy-nilly\".\n> \n> I don't agree. The way I read it is that it means that if your program\n> receives colored input, it is not obligated to strip it out, but it is\n> obligated not to add any.\n\nThe very example they give says otherwise:\n\n It is reasonable to configure certain software such as a text editor\n to use color\n\nThey are saying a text editor adding color is *fine*.\n\n> NO_COLOR=1 says, \"I don't want color, but I have a fully functional\n> terminal I would like to use, thank you.\"\n\nThat's not what it says.\n\n> In other words, I think in this case, the user has opted to configure\n> their editor as they like it and invoke it without NO_COLOR, but has\n> instructed other programs to not add color with NO_COLOR.\n\nThat is a reasonable interpretation... until you read the next\nanswer:\n\n A user should be able to export $NO_COLOR in their shell configuration\n file as a default, but configure a specific program in its\n configuration file to specifically enable color.\n\nThe whole point is not to configure each program to disable color, but\nhave a global NO_COLOR.\n\nSo I don't think your interpretation is correct.\n\n-- \nFelipe Contreras"},{"id":"425234","messageId":"8811383b-d5f1-2b06-8ac7-47bbc5fc9d20@gmail.com","threadId":"55714","inReplyTo":"60a7f7427eab6_55039208ba@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-21T19:48:17Z","receivedAt":"2021-05-21T19:48:36Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"Hi all,\n\nIf I may, NO_COLOR approach seems to be rather straightforward to me, \nas per description on their homepage[1] - make all software supporting \nit behave as colors are an opt-in feature, thus disabled by default.\n\nAnd that's all there is to it.\n\nSoftware which is able to but does not show any colors by default does \nnot need to care at all, as colors are an opt-in feature there already, \nso NO_COLOR serves no purpose.\n\nOn the other hand, software which does enable (at least some) color \nby default, without user explicitly setting anything but requiring \nopt-out to disable color instead, should treat NO_COLOR precisely as \nthat user requested opt-out, with an obvious convenience for the user \nbeing able to set NO_COLOR globally once and have all the programs \nsupporting it recognize it as color opt-out exactly, without a need \nfor the user to opt-out in each and every program separately \n(and differently).\n\nSo, the whole point is make the default value be \"no color\" for each \nand every application consistently, where user (and _not_ developer) \nneeds to opt-in in order to enable colors (in each and every \napplication where colors are in fact still desired).\n\nRegards, Buga\n--\n[1]: https://no-color.org/\n"},{"id":"425240","messageId":"60a8243323625_77e4f208f8@natae.notmuch","threadId":"55714","inReplyTo":"8811383b-d5f1-2b06-8ac7-47bbc5fc9d20@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-21T21:20:51Z","receivedAt":"2021-05-21T21:20:57Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Igor Djordjevic wrote:\n> If I may, NO_COLOR approach seems to be rather straightforward to me, \n> as per description on their homepage[1] - make all software supporting \n> it behave as colors are an opt-in feature, thus disabled by default.\n\nMay I ask you how you interpret this?\n\n It is reasonable to configure certain software such as a text editor\n to use color ... sparingly\n\n-- \nFelipe Contreras\n"},{"id":"425242","messageId":"636007b7-c079-f8a6-1b26-eb2a55505354@gmail.com","threadId":"55714","inReplyTo":"60a8243323625_77e4f208f8@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-21T22:10:38Z","receivedAt":"2021-05-21T22:10:49Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 21/05/2021 23:20, Felipe Contreras wrote:\n> Igor Djordjevic wrote:\n> > \n> > If I may, NO_COLOR approach seems to be rather straightforward to me, \n> > as per description on their homepage[1] - make all software supporting \n> > it behave as colors are an opt-in feature, thus disabled by default.\n> \n> May I ask you how you interpret this?\n> \n> It is reasonable to configure certain software such as a text editor\n> to use color ... sparingly\n\nSure, but to make the point (hopefully) even more obvious, let me \nquote the whole part:\n\n It is reasonable to configure certain software such as a text editor \n to use color or other ANSI attributes sparingly (such as the reverse \n attribute for a status bar) while still desiring that other software \n not add color unless configured to. It should be up to the user \n whether color is used, not the software author.\n\nI understand it exactly as (I think) it says - it is reasonable to \nallow (the user, not developer!) to configure certain software to \n(still) use color (fully or sparingly should not even matter, and it \nmay depend on what kind of granular configuration software allows in \nthe first place, if any), even if his (user's) general (\"default\") \npreference is to have no colors.\n\nThus color should be user opt-in - NO_COLOR turns all of it off by \ndefault (for all software supporting it), and user decides which color \nto turn back on through each specific software color configuration.\n\nThat last sentence should make it clear - \"it should be up to the \nuser whether color is used, not the software author\".\n\nSo it shouldn't matter what does software author think about which \nparts of software should be (fully or sparingly) colored (by default) \n- NO_COLOR's idea is to give the ultimate power to the user to \ndecide, and on a global level, starting with no colors by default, \nthen allowing colors where desired, per each specific software config \n(instead of vice-versa, being required to turn color off per each \nspecific software, where color is otherwise used by default).\n\nAt least that's how I understand all of it, making sense to me, but I \ndon't mind discussing it further, if needed.\n"},{"id":"425276","messageId":"d18b09f5-6a6f-6fdb-bdd2-e63156c7ce9d@gmail.com","threadId":"55714","inReplyTo":"8811383b-d5f1-2b06-8ac7-47bbc5fc9d20@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-21T22:47:01Z","receivedAt":"2021-05-21T22:47:12Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"On 21/05/2021 21:48, Igor Djordjevic wrote:\n> \n> So, the whole point is make the default value be \"no color\" for each \n> and every application consistently, where user (and _not_ developer) \n> needs to opt-in in order to enable colors (in each and every \n> application where colors are in fact still desired).\n\nOh, and might be what NO_COLOR homepage provides as a tip for \n\"disabling color in software not supporting NO_COLOR\" for Git \nspecifically might be a good (and enough of a) clue by itself...?\n\n git config --global color.ui false\n\nSo I'd argue that Git should react to NO_COLOR exactly as it should \nreact to `color.ui` set to false - disabling all color.\n\nDo note it's only by default, in case no (other) color configuration is \nspecified - any existing user config should take precedence, of course, \nfurther acting as per user's desire (\"... NO_COLOR says I prefer no \ncolor in general, but I do want color in this specific case, enabled by \nsetting this software specific config option explicitly...\").\n"},{"id":"425279","messageId":"60a83c794ed4d_81cd4208f3@natae.notmuch","threadId":"55714","inReplyTo":"636007b7-c079-f8a6-1b26-eb2a55505354@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-21T23:04:25Z","receivedAt":"2021-05-21T23:04:34Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Igor Djordjevic wrote:\n> On 21/05/2021 23:20, Felipe Contreras wrote:\n> > Igor Djordjevic wrote:\n> > > \n> > > If I may, NO_COLOR approach seems to be rather straightforward to me, \n> > > as per description on their homepage[1] - make all software supporting \n> > > it behave as colors are an opt-in feature, thus disabled by default.\n> > \n> > May I ask you how you interpret this?\n> > \n> > It is reasonable to configure certain software such as a text editor\n> > to use color ... sparingly\n> \n> Sure, but to make the point (hopefully) even more obvious, let me \n> quote the whole part:\n> \n> It is reasonable to configure certain software such as a text editor \n> to use color or other ANSI attributes sparingly (such as the reverse \n> attribute for a status bar) while still desiring that other software \n> not add color unless configured to. It should be up to the user \n> whether color is used, not the software author.\n> \n> I understand it exactly as (I think) it says - it is reasonable to \n> allow (the user, not developer!) to configure certain software to \n> (still) use color\n\nThis does not follow.\n\nThe contraposition of that statement is that if a text editor doesn't\nuse color sparingly, then the user should not be allowed to configure\nsuch software.\n\nDo you really think that's what they are saying? The user should not\nhave a choice? (with certain software) That's color fascism.\n\n-- \nFelipe Contreras\n"},{"id":"425282","messageId":"xmqqpmxjr7cs.fsf@gitster.g","threadId":"55714","inReplyTo":"8811383b-d5f1-2b06-8ac7-47bbc5fc9d20@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-21T23:32:19Z","receivedAt":"2021-05-21T23:32:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Igor Djordjevic writes:\n\n> Hi all,\n>\n> If I may, NO_COLOR approach seems to be rather straightforward to me, \n> as per description on their homepage[1] - make all software supporting \n> it behave as colors are an opt-in feature, thus disabled by default.\n\nYes, that is correct and this was discussed already in detail a few\ndays ago. You can start from here:\n\n https://lore.kernel.org/git/YKRSlFcFAcHcR3uY@camp.crustytoothpaste.net/\n\nand read two or three messages.\n\nNote that you probably want to take generic NO_COLOR support\n(i.e. teaching the \"now we know the user wants the 'default'\nbehaviour by not having an explicit 'yes/no'; do we want to color\nthe output?\" helper function to pay attention to the environment\nvariable) as taken by somebody already:\n\n https://lore.kernel.org/git/YKcFrbuuJrWAxXgm@camp.crustytoothpaste.net/\n\nThanks.\n"},{"id":"425339","messageId":"e669d76b-0bed-4eac-a942-c89b7523ca34@gmail.com","threadId":"55714","inReplyTo":"60a83c794ed4d_81cd4208f3@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-22T18:38:34Z","receivedAt":"2021-05-22T18:38:47Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"\nOn 22/05/2021 01:04, Felipe Contreras wrote:\n> Igor Djordjevic wrote:\n> >\n> > ... to make the point (hopefully) even more obvious, let me \n> > quote the whole part:\n> >\n> > It is reasonable to configure certain software such as a text editor \n> > to use color or other ANSI attributes sparingly (such as the reverse \n> > attribute for a status bar) while still desiring that other software \n> > not add color unless configured to. It should be up to the user \n> > whether color is used, not the software author.\n> >\n> > I understand it exactly as (I think) it says - it is reasonable to \n> > allow (the user, not developer!) to configure certain software to \n> > (still) use color\n> \n> This does not follow.\n\nSure, if that is the only part you read (\"followed\"), taking it out \nof context while chopping the rest...\n\n> The contraposition of that statement is that if a text editor doesn't\n> use color sparingly, then the user should not be allowed to configure\n> such software.\n> \n> Do you really think that's what they are saying? The user should not\n> have a choice? (with certain software) That's color fascism.\n\nWhat I really think is that my message which you replied to - but \ndecided to quote only _sparingly_ ;) - already addressed both use of \n\"sparingly\" and who should have the choice (not to say all the power) \nin a very clear and explicit manner (hint: user exactly), so I'm afraid \nI'd have nothing more to add, sorry.\n\nRegards, Buga\n\np.s. Oh, and please do allow me to _opt-in_ the missing part of my \nmessage back :) (for whatever that will be worth, eh):\n\n> > I understand it exactly as (I think) it says - it is reasonable to \n> > allow (the user, not developer!) to configure certain software to \n> > (still) use color (fully or sparingly should not even matter, and it \n> > may depend on what kind of granular configuration software allows in \n> > the first place, if any), even if his (user's) general (\"default\") \n> > preference is to have no colors.\n> > \n> > Thus color should be user opt-in - NO_COLOR turns all of it off by \n> > default (for all software supporting it), and user decides which color \n> > to turn back on through each specific software color configuration.\n> > \n> > That last sentence should make it clear - \"it should be up to the \n> > user whether color is used, not the software author\".\n> > \n> > So it shouldn't matter what does software author think about which \n> > parts of software should be (fully or sparingly) colored (by default) \n> > - NO_COLOR's idea is to give the ultimate power to the user to \n> > decide, and on a global level, starting with no colors by default, \n> > then allowing colors where desired, per each specific software config \n> > (instead of vice-versa, being required to turn color off per each \n> > specific software, where color is otherwise used by default).\n"},{"id":"425351","messageId":"60a97c12d96a_85723208d4@natae.notmuch","threadId":"55714","inReplyTo":"e669d76b-0bed-4eac-a942-c89b7523ca34@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-22T21:48:02Z","receivedAt":"2021-05-22T21:48:08Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Igor Djordjevic wrote:\n> \n> On 22/05/2021 01:04, Felipe Contreras wrote:\n> > Igor Djordjevic wrote:\n> > >\n> > > ... to make the point (hopefully) even more obvious, let me \n> > > quote the whole part:\n> > >\n> > > It is reasonable to configure certain software such as a text editor \n> > > to use color or other ANSI attributes sparingly (such as the reverse \n> > > attribute for a status bar) while still desiring that other software \n> > > not add color unless configured to. It should be up to the user \n> > > whether color is used, not the software author.\n> > >\n> > > I understand it exactly as (I think) it says - it is reasonable to \n> > > allow (the user, not developer!) to configure certain software to \n> > > (still) use color\n> > \n> > This does not follow.\n> \n> Sure, if that is the only part you read (\"followed\"), taking it out \n> of context while chopping the rest...\n\nLanguage is understood bit by bit. To properly understand the sentences\nthat follow you first need to understand the sentences that preceed.\n\n> > The contraposition of that statement is that if a text editor doesn't\n> > use color sparingly, then the user should not be allowed to configure\n> > such software.\n> > \n> > Do you really think that's what they are saying? The user should not\n> > have a choice? (with certain software) That's color fascism.\n> \n> What I really think is that my message which you replied to - but \n> decided to quote only _sparingly_ ;) - already addressed both use of \n> \"sparingly\" and who should have the choice (not to say all the power) \n> in a very clear and explicit manner (hint: user exactly), so I'm afraid \n> I'd have nothing more to add, sorry.\n\nI know what you said in the rest of the message, which is precisely why\nit does not follow, and since you ignored my argument, let me state it\nwith logic symbols for the record.\n\n It is reasonable to configure certain software such as a text editor\n to use color or other ANSI attributes sparingly (such as the reverse\n attribute for a status bar)\n\nWe extract part of the message:\n\n It is reasonable to configure a text editor to use color sparingly\n\nThe first sentence implies the second, no information is changed.\n\n---\n\nYou interpret that as:\n\n It is reasonable to allow the user to configure a text editor to use\n color sparingly\n\nThis is obviously a different sentence. You introduced a part that was\nnot there.\n\nNow we use logic symbols to transform your sentence:\n\n p = the user configures a text editor to use color sparingly\n q = it is reasonable to allow the user\n\nThis is what you said: if p -> q. The contraposition is: ~q -> ~p.\n\nTherefore you said:\n\n It is not reasonable to allow the user to configure a text editor to\n not use color sparingly.\n\nThis is a fact.\n\nWhat you said doesn't make sense.\n\n---\n\nThis what no-color.org said:\n\n It is reasonable to configure a text editor to use color sparingly\n\nBy doing the same contraposition as above we get that it's the same as:\n\n It is not reasonale to configure a text editor to not use color\n sparingly.\n\nOr in other words.\n\n It is not reasonable to configure a text editor to use colors heavily.\n\nIf it's the developers doing that, then that statement is correct.\n\nThis is my interpretation. My interpretation holds to scrutiny; yours\ndoes not.\n\nThey meant the developers. They are not trying to tell users what to do.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"425377","messageId":"6642528a-b270-5862-bfdc-7bfa22682c2f@gmail.com","threadId":"55714","inReplyTo":"60a97c12d96a_85723208d4@natae.notmuch","subject":"Re: [PATCH] help: colorize man pages","fromName":"Igor Djordjevic","fromEmail":"igor.d.djordjevic@gmail.com","sentAt":"2021-05-23T11:25:59Z","receivedAt":"2021-05-23T11:26:12Z","isPatch":true,"sender":{"key":"igor.d.djordjevic@gmail.com","avatar":null},"body":"\nOn 22/05/2021 23:48, Felipe Contreras wrote:\n> \n> Language is understood bit by bit. To properly understand the sentences\n> that follow you first need to understand the sentences that preceed.\n\nExcept you can't deliberately chop and butcher mentioned sentences in \norder to \"understand\" them in isolation, as the meaning is largely \ndetermined by context - and yes, the following sentences as well.\n\nYou focus on seeing the trees, but you're missing the forest.\n\n> I know what you said in the rest of the message, which is precisely why\n> it does not follow, and since you ignored my argument, let me state it\n> with logic symbols for the record.\n> \n> It is reasonable to configure certain software such as a text editor\n> to use color or other ANSI attributes sparingly (such as the reverse\n> attribute for a status bar)\n> \n> We extract part of the message:\n> \n> It is reasonable to configure a text editor to use color sparingly\n> \n> The first sentence implies the second, no information is changed.\n> \n> ---\n> \n> You interpret that as:\n> \n> It is reasonable to allow the user to configure a text editor to use\n> color sparingly\n> \n> This is obviously a different sentence. You introduced a part that was\n> not there.\n> \n> Now we use logic symbols to transform your sentence:\n> \n> p = the user configures a text editor to use color sparingly\n> q = it is reasonable to allow the user\n> \n> This is what you said: if p -> q. The contraposition is: ~q -> ~p.\n> \n> Therefore you said:\n> \n> It is not reasonable to allow the user to configure a text editor to\n> not use color sparingly.\n> \n> This is a fact.\n> \n> What you said doesn't make sense.\n> \n> ---\n> \n> This what no-color.org said:\n> \n> It is reasonable to configure a text editor to use color sparingly\n> \n> By doing the same contraposition as above we get that it's the same as:\n> \n> It is not reasonale to configure a text editor to not use color\n> sparingly.\n> \n> Or in other words.\n> \n> It is not reasonable to configure a text editor to use colors heavily.\n> \n> If it's the developers doing that, then that statement is correct.\n> \n> This is my interpretation. My interpretation holds to scrutiny; yours\n> does not.\n> \n> They meant the developers. They are not trying to tell users what to do.\n> \n> Cheers.\n\nYou are overthinking the whole thing (or the piece(s) you focused on, in \nfact missing the thing as a whole completely), making it unnecessarily \ncomplicated for yourself.\n\nThe NO_COLOR[1] homepage text, read in its entirety and even if not \nperfect, seems clear enough for everyone who wants to understand it. \nI'm sorry if it's not clear for you, I'm afraid I can't help any \nfurther.\n\nAnd while I find your armchair analysis amusing, you'll pardon me for \nnot taking any more part in it as, unfortunately, I don't have that \nmuch time at my hands to waste.\n\nCheers, Buga\n--\n[1]: https://no-color.org/\n"},{"id":"425380","messageId":"60aa6b48c0623_1234e6208ac@natae.notmuch","threadId":"55714","inReplyTo":"6642528a-b270-5862-bfdc-7bfa22682c2f@gmail.com","subject":"Re: [PATCH] help: colorize man pages","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-23T14:48:40Z","receivedAt":"2021-05-23T14:48:45Z","isPatch":true,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Igor Djordjevic wrote:\n> \n> On 22/05/2021 23:48, Felipe Contreras wrote:\n> > \n> > Language is understood bit by bit. To properly understand the sentences\n> > that follow you first need to understand the sentences that preceed.\n> \n> Except you can't deliberately chop and butcher mentioned sentences in \n> order to \"understand\" them in isolation, as the meaning is largely \n> determined by context - and yes, the following sentences as well.\n\nPlease explain the context that makes this sentense makes ense:\n\n It is not reasonable to allow the user to configure a text editor to\n not use color heavily.\n\n> The NO_COLOR[1] homepage text, read in its entirety and even if not \n> perfect, seems clear enough for everyone who wants to understand it. \n\nYes, it is clear: software who use colors heavily should respect\nNO_COLOR.\n\nOthers on this list agree.\n\n-- \nFelipe Contreras\n"}]}