{"thread":{"id":"55699","subject":"Man pages have colors? A deep dive into groff","startedAt":"2021-05-15T22:10:48Z","lastAt":"2021-05-18T14:27:39Z","messageCount":15,"participants":["Felipe Contreras","Ævar Arnfjörð Bjarmason","Junio C Hamano","Randall S. Becker","brian m. carlson","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"424668","messageId":"60a046bd83001_f4b0f20861@natae.notmuch","threadId":"55699","inReplyTo":null,"subject":"Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-15T22:10:05Z","receivedAt":"2021-05-15T22:10:48Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Hi,\n\nWhile I was doing the investigagion for my GNU_ROFF patch [1], I checked\ndifferent versions of all the tools (asciidoc, asciidoctor, docbook, and\ngroff).\n\nWhen I tested my own compiled version of groff I noticed something\nweird: man pages have colors. This did not happen with the version\nshipped by Arch Linux.\n\nI did notice the output generated by docbook stylesheets showed\n\\m[blue], but no color showed up.\n\nIt turns out Arch Linux disables colors, and so does Debian, by\ndisabling a feature called SGR. This happened about 10 years, and the\nrationale was that \"it doesn't work correctly\".\n\nTo enable SGR on these distributions you need to do GROFF_SGR=1, but\nthat is not documented anywhere.\n\ngroff does check for a variable GROFF_NO_SGR, but it's the other way\naround: SGR is enabled unless that variable is set.\n\nThere's other ways your distribution might be screwing up with groff\n(for example Arch Linux converts \\' to ', which is not correct), so you\nmight want to check your shipped configuration in:\n\n /usr/share/groff/site-tmac/man.local\n\nUnfortunately the colors in man pages leave a lot to be desired.\n\nHere is a simple trick I've been using to show some custom colors:\n\n man() {\n GROFF_NO_SGR=1 \\\n LESS_TERMCAP_md=$'\\e[1;31m' \\\n LESS_TERMCAP_me=$'\\e[0m' \\\n LESS_TERMCAP_us=$'\\e[1;34m' \\\n LESS_TERMCAP_ue=$'\\e[0m' \\\n LESS_TERMCAP_so=$'\\e[1;35m' \\\n LESS_TERMCAP_se=$'\\e[0m' \\\n command man \"$@\"\n }\n\nHopefully some of you might find this useful.\n\nCheers.\n\n[1] https://lore.kernel.org/git/20210515115653.922902-2-felipe.contreras@gmail.com/\n\n-- \nFelipe Contreras\n"},{"id":"424763","messageId":"87tun1qp91.fsf@evledraar.gmail.com","threadId":"55699","inReplyTo":"60a046bd83001_f4b0f20861@natae.notmuch","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2021-05-17T16:48:04Z","receivedAt":"2021-05-17T16:51:37Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, May 15 2021, Felipe Contreras wrote:\n\n> Hi,\n>\n> While I was doing the investigagion for my GNU_ROFF patch [1], I checked\n> different versions of all the tools (asciidoc, asciidoctor, docbook, and\n> groff).\n>\n> When I tested my own compiled version of groff I noticed something\n> weird: man pages have colors. This did not happen with the version\n> shipped by Arch Linux.\n>\n> I did notice the output generated by docbook stylesheets showed\n> \\m[blue], but no color showed up.\n>\n> It turns out Arch Linux disables colors, and so does Debian, by\n> disabling a feature called SGR. This happened about 10 years, and the\n> rationale was that \"it doesn't work correctly\".\n>\n> To enable SGR on these distributions you need to do GROFF_SGR=1, but\n> that is not documented anywhere.\n>\n> groff does check for a variable GROFF_NO_SGR, but it's the other way\n> around: SGR is enabled unless that variable is set.\n>\n> There's other ways your distribution might be screwing up with groff\n> (for example Arch Linux converts \\' to ', which is not correct), so you\n> might want to check your shipped configuration in:\n>\n> /usr/share/groff/site-tmac/man.local\n>\n> Unfortunately the colors in man pages leave a lot to be desired.\n>\n> Here is a simple trick I've been using to show some custom colors:\n>\n> man() {\n> GROFF_NO_SGR=1 \\\n> LESS_TERMCAP_md=$'\\e[1;31m' \\\n> LESS_TERMCAP_me=$'\\e[0m' \\\n> LESS_TERMCAP_us=$'\\e[1;34m' \\\n> LESS_TERMCAP_ue=$'\\e[0m' \\\n> LESS_TERMCAP_so=$'\\e[1;35m' \\\n> LESS_TERMCAP_se=$'\\e[0m' \\\n> command man \"$@\"\n> }\n>\n> Hopefully some of you might find this useful.\n>\n> Cheers.\n>\n> [1] https://lore.kernel.org/git/20210515115653.922902-2-felipe.contreras@gmail.com/\n\nThis looks much better.\n\nI wonder a good follow-up (hint, hint! :) would be to have\nexec_man_man() and exec_man_cmd() in builtin/help.c set this depending\non color.ui (so we'd do it by default with \"auto\").\n\nThen e.g. \"git help git\" would look prettier than \"man git\".\n"},{"id":"424775","messageId":"xmqqlf8d6ty5.fsf@gitster.g","threadId":"55699","inReplyTo":"87tun1qp91.fsf@evledraar.gmail.com","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-17T19:28:34Z","receivedAt":"2021-05-17T19:28:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> This looks much better.\n>\n> I wonder a good follow-up (hint, hint! :) would be to have\n> exec_man_man() and exec_man_cmd() in builtin/help.c set this depending\n> on color.ui (so we'd do it by default with \"auto\").\n>\n> Then e.g. \"git help git\" would look prettier than \"man git\".\n\nAs long as color.man.ui can be used to override the blanket\ncolor.ui, I think it is a good idea.\n"},{"id":"424791","messageId":"60a2f1c4cab0d_13c3702083a@natae.notmuch","threadId":"55699","inReplyTo":"xmqqlf8d6ty5.fsf@gitster.g","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-17T22:44:20Z","receivedAt":"2021-05-17T22:44:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Junio C Hamano wrote:\n> Ævar Arnfjörð Bjarmason writes:\n> \n> > This looks much better.\n> >\n> > I wonder a good follow-up (hint, hint! :) would be to have\n> > exec_man_man() and exec_man_cmd() in builtin/help.c set this depending\n> > on color.ui (so we'd do it by default with \"auto\").\n> >\n> > Then e.g. \"git help git\" would look prettier than \"man git\".\n> \n> As long as color.man.ui can be used to override the blanket\n> color.ui, I think it is a good idea.\n\nWhy not use color.pager?\n\n-- \nFelipe Contreras"},{"id":"424792","messageId":"00b701d74b6f$aa295ed0$fe7c1c70$@nexbridge.com","threadId":"55699","inReplyTo":"60a2f1c4cab0d_13c3702083a@natae.notmuch","subject":"RE: Man pages have colors? A deep dive into groff","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-17T22:54:54Z","receivedAt":"2021-05-17T22:55:07Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 17, 2021 6:44 PM, Felipe Contreras wrote:\n>Junio C Hamano wrote:\n>> Ævar Arnfjörð Bjarmason writes:\n>>\n>> > This looks much better.\n>> >\n>> > I wonder a good follow-up (hint, hint! :) would be to have\n>> > exec_man_man() and exec_man_cmd() in builtin/help.c set this\n>> > depending on color.ui (so we'd do it by default with \"auto\").\n>> >\n>> > Then e.g. \"git help git\" would look prettier than \"man git\".\n>>\n>> As long as color.man.ui can be used to override the blanket color.ui,\n>> I think it is a good idea.\n>\n>Why not use color.pager?\n\nI think there is a lesson to be learned from git checkout; specifically not to overload semantics. Manual representation is a presentation world unto itself that has should not be blended with programs like less. More than that, being someone who loves automated documentation generation, manual representation has a broader semantic that should not be dismissed. There are probably a whole class of colours that ultimately might be requested - might be me - so I'd rather not blend these into color.pager.\n\nJust my tuppence. \n\n-Randall\n\n"},{"id":"424793","messageId":"60a2fd5d52740_1461a92083d@natae.notmuch","threadId":"55699","inReplyTo":"00b701d74b6f$aa295ed0$fe7c1c70$@nexbridge.com","subject":"RE: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-17T23:33:49Z","receivedAt":"2021-05-17T23:33:54Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Randall S. Becker wrote:\n> On May 17, 2021 6:44 PM, Felipe Contreras wrote:\n> >Junio C Hamano wrote:\n> >> Ævar Arnfjörð Bjarmason writes:\n> >>\n> >> > This looks much better.\n> >> >\n> >> > I wonder a good follow-up (hint, hint! :) would be to have\n> >> > exec_man_man() and exec_man_cmd() in builtin/help.c set this\n> >> > depending on color.ui (so we'd do it by default with \"auto\").\n> >> >\n> >> > Then e.g. \"git help git\" would look prettier than \"man git\".\n> >>\n> >> As long as color.man.ui can be used to override the blanket color.ui,\n> >> I think it is a good idea.\n> >\n> >Why not use color.pager?\n> \n> I think there is a lesson to be learned from git checkout;\n> specifically not to overload semantics.\n\n> Manual representation is a presentation world unto itself that has\n> should not be blended with programs like less.\n\nHuh? man is basically a grapper for `groff | less`:\n\nFrom man(1): \"man is the system's manual pager\".\n\nYou could use it for other purposes, like generating DVI files, but\nthat's not how git uses it. We it in the normal mode, which uses\nthe environment variable MANPAGER.\n\nThis has absolutely nothing to do with man:\n\n export GROFF_NO_SGR=1\n export LESS_TERMCAP_md=$'\\e[1;31m'\n export LESS_TERMCAP_me=$'\\e[m'\n zcat /usr/share/man/man1/git.1.gz | groff -T utf8 -m man | less -R\n\n> More than that, being someone who loves automated\n> documentation generation, manual representation has a broader semantic\n> that should not be dismissed.\n\nBut what does that have to do with `git help`?\n\n> There are probably a whole class of colours that ultimately might be\n> requested - might be me - so I'd rather not blend these into\n> color.pager.\n\nBut it's 100% pager-dependent. Not only do you need a pager for this to\nwork, but you need specifically the `less` pager.\n\nThis:\n\n MANPAGER=more git -c color.man=always help git\n\nWould not work, because `more` doesn't read use the LESS_TERMCAP variables.\n\nSo why call it color.man, if it's not really a man thing?\n\nCheers.\n\n-- \nFelipe Contreras"},{"id":"424800","messageId":"xmqqim3g4ys5.fsf@gitster.g","threadId":"55699","inReplyTo":"60a2f1c4cab0d_13c3702083a@natae.notmuch","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-18T01:27:06Z","receivedAt":"2021-05-18T01:27:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras writes:\n\n> Junio C Hamano wrote:\n>> Ævar Arnfjörð Bjarmason writes:\n>> \n>> > This looks much better.\n>> >\n>> > I wonder a good follow-up (hint, hint! :) would be to have\n>> > exec_man_man() and exec_man_cmd() in builtin/help.c set this depending\n>> > on color.ui (so we'd do it by default with \"auto\").\n>> >\n>> > Then e.g. \"git help git\" would look prettier than \"man git\".\n>> \n>> As long as color.man.ui can be used to override the blanket\n>> color.ui, I think it is a good idea.\n>\n> Why not use color.pager?\n\nI dug a bit to refresh my memory and it turns out that the reason we\nshould not do so is because it means something totally different.\n\ncolor.[ch] defines want_color() that applications like \"diff\" and\n\"log\" can use to see if the application is configured to paint its\noutput in colors.\n\nWhen that layer says for that particular application it should be\ndecided automatically, then we call into color.c::check_auto_color()\nwhich is the only user of pager_use_color (which is set from the\ncolor.pager configuration variable). The purpose of that call is to\nask if the pager is capable of colors.\n\nSo in short, the color.pager is about \"is the pager capable of\ncolors?\" and the color.ui (and color.) is about \"does the user\nwants output from in color?\" We need to use color.help or\nsomething that controls whether the user wants help/man in colors,\nand perhaps default it to \"auto\" like color.ui defaults to, which\nthen in turn would consult \"color.pager\". Tying it directly to\n\"color.pager\" is wrong.\n\n\n\n\n"},{"id":"424801","messageId":"YKMYUUVVVJMWH7xi@camp.crustytoothpaste.net","threadId":"55699","inReplyTo":"87tun1qp91.fsf@evledraar.gmail.com","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2021-05-18T01:28:49Z","receivedAt":"2021-05-18T01:29:27Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2021-05-17 at 16:48:04, Ævar Arnfjörð Bjarmason wrote:\n> This looks much better.\n> \n> I wonder a good follow-up (hint, hint! :) would be to have\n> exec_man_man() and exec_man_cmd() in builtin/help.c set this depending\n> on color.ui (so we'd do it by default with \"auto\").\n> \n> Then e.g. \"git help git\" would look prettier than \"man git\".\n\nAs I mentioned on the patch itself, I'd prefer if Git didn't do this. I\nhave my own colors configured and don't want Git to render its man\noutput differently from what I have. Even if I didn't, I wouldn't want\nGit to change the output of man(1) to be different from what's on the\nsystem.\n\nI should point out that I have my shell configuration set up to use\ndifferent colors depending on the capability of the terminal, such as\nusing a 256-color palette when that's supported and a 16-color palette\nwhen it's not, so there is literally no configuration that Git can\nprovide here that matches my existing settings.\n\nAdditionally, colors tend to pose accessibility problems for a lot of\npeople. I have normal color vision, but because I use a transparent\nbackground which renders as grey, the standard terminal red is nearly\nillegible for me. I also know people with colorblindness who have\nproblems with various colors or any colors at all.\n-- \nbrian m. carlson (he/him or they/them)\nHouston, Texas, US\n"},{"id":"424807","messageId":"xmqqeee44wp4.fsf@gitster.g","threadId":"55699","inReplyTo":"YKMYUUVVVJMWH7xi@camp.crustytoothpaste.net","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-18T02:12:07Z","receivedAt":"2021-05-18T02:12:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" writes:\n\n> As I mentioned on the patch itself, I'd prefer if Git didn't do this. I\n> have my own colors configured and don't want Git to render its man\n> output differently from what I have. Even if I didn't, I wouldn't want\n> Git to change the output of man(1) to be different from what's on the\n> system.\n>\n> I should point out that I have my shell configuration set up to use\n> different colors depending on the capability of the terminal, such as\n> using a 256-color palette when that's supported and a 16-color palette\n> when it's not, so there is literally no configuration that Git can\n> provide here that matches my existing settings.\n\ngit -c color.man=false help -m\" would let you consume the output in\nany way you want, I would presume?\n\n> Additionally, colors tend to pose accessibility problems for a lot of\n> people. I have normal color vision, but because I use a transparent\n> background which renders as grey, the standard terminal red is nearly\n> illegible for me. I also know people with colorblindness who have\n> problems with various colors or any colors at all.\n\nYes, accessibility issues are real. But a bit of configuration to\ndisable colors would rescue our users. I work on white-background\nwith black pixels, and colored diff output that shows lost lines on\nthe same background with red pixels is hard to read for me, but\nthanks to color.diff. settings, I can customize it to draw in\nreverse colors.\n"},{"id":"424819","messageId":"60a3422b9556c_14d1bc2082f@natae.notmuch","threadId":"55699","inReplyTo":"xmqqim3g4ys5.fsf@gitster.g","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T04:27:23Z","receivedAt":"2021-05-18T04:27:31Z","isPatch":false,"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> > Why not use color.pager?\n> \n> I dug a bit to refresh my memory and it turns out that the reason we\n> should not do so is because it means something totally different.\n> \n> color.[ch] defines want_color() that applications like \"diff\" and\n> \"log\" can use to see if the application is configured to paint its\n> output in colors.\n> \n> When that layer says for that particular application it should be\n> decided automatically, then we call into color.c::check_auto_color()\n> which is the only user of pager_use_color (which is set from the\n> color.pager configuration variable). The purpose of that call is to\n> ask if the pager is capable of colors.\n\nThat is not true. check_auto_color() returns 1 when the fd is a tty.\n\nFor example advice() would indirectly call check_auto_color() and no\npager is involved.\n\nInside the help built-in want_color(GIT_COLOR_UNKNOWN) will always\nreturn 1 (unless you do something like `git help git > file`).\n\npager_use_color is completely ignored in this case.\n\nIt's used only when 1) the fd is not a tty, 2) it's stdout, 3) git is\nusing a pager... Only _then_ it checks for pager_use_color\n(color.pager).\n\nSo no; the first purpose of check_auto_color() is to find out if the fd\nis capable of showing colors, secondary, if we are using a pager, then\ncheck the user configuration.\n\nIn the case we are using a pager it's not check if the pager is capable\nof colors, the pager could be capable of colors and yet the user would\ndisable them: it's the check for the user preference.\n\n> So in short, the color.pager is about \"is the pager capable of\n> colors?\"\n\nThat's not the case.\n\nEven the documentation says so:\n\n color.pager::\n A boolean to enable/disable colored output when the pager is in\n use (default is true).\n\n> and the color.ui (and color.) is about \"does the user\n> wants output from in color?\"\n\n> Tying it directly to \"color.pager\" is wrong.\n\nWhy? color.pager is to enable/disable colored output when a pager is in\nuse.\n\nThe fact that it's man executing the pager and not git makes no\ndifference to the user.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"424820","messageId":"60a343226a0ab_14d1bc208f8@natae.notmuch","threadId":"55699","inReplyTo":"YKMYUUVVVJMWH7xi@camp.crustytoothpaste.net","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T04:31:30Z","receivedAt":"2021-05-18T04:31:34Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"brian m. carlson wrote:\n> On 2021-05-17 at 16:48:04, Ævar Arnfjörð Bjarmason wrote:\n> > This looks much better.\n> > \n> > I wonder a good follow-up (hint, hint! :) would be to have\n> > exec_man_man() and exec_man_cmd() in builtin/help.c set this depending\n> > on color.ui (so we'd do it by default with \"auto\").\n> > \n> > Then e.g. \"git help git\" would look prettier than \"man git\".\n> \n> As I mentioned on the patch itself, I'd prefer if Git didn't do this. I\n> have my own colors configured and don't want Git to render its man\n> output differently from what I have.\n\nIt won't.\n\n> Even if I didn't, I wouldn't want Git to change the output of man(1)\n> to be different from what's on the system.\n\nThat's a preference others don't share.\n\n> I should point out that I have my shell configuration set up to use\n> different colors depending on the capability of the terminal, such as\n> using a 256-color palette when that's supported and a 16-color palette\n> when it's not, so there is literally no configuration that Git can\n> provide here that matches my existing settings.\n\nOnce again; your configuration is not going to be overridden.\n\n> Additionally, colors tend to pose accessibility problems for a lot of\n> people. I have normal color vision, but because I use a transparent\n> background which renders as grey, the standard terminal red is nearly\n> illegible for me. I also know people with colorblindness who have\n> problems with various colors or any colors at all.\n\nTheir configuration won't be overridden either.\n\n-- \nFelipe Contreras"},{"id":"424821","messageId":"60a3440d3f76e_14d1bc208ed@natae.notmuch","threadId":"55699","inReplyTo":"xmqqeee44wp4.fsf@gitster.g","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T04:35:25Z","receivedAt":"2021-05-18T04:35:46Z","isPatch":false,"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> > As I mentioned on the patch itself, I'd prefer if Git didn't do this. I\n> > have my own colors configured and don't want Git to render its man\n> > output differently from what I have. Even if I didn't, I wouldn't want\n> > Git to change the output of man(1) to be different from what's on the\n> > system.\n> >\n> > I should point out that I have my shell configuration set up to use\n> > different colors depending on the capability of the terminal, such as\n> > using a 256-color palette when that's supported and a 16-color palette\n> > when it's not, so there is literally no configuration that Git can\n> > provide here that matches my existing settings.\n> \n> git -c color.man=false help -m\" would let you consume the output in\n> any way you want, I would presume?\n\nHis configuration won't be overridden. He doesn't need to change\na thing.\n\n-- \nFelipe Contreras\n"},{"id":"424837","messageId":"YKNptH9DL6pe18Dk@coredump.intra.peff.net","threadId":"55699","inReplyTo":"60a3422b9556c_14d1bc2082f@natae.notmuch","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-05-18T07:16:04Z","receivedAt":"2021-05-18T07:16:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 17, 2021 at 11:27:23PM -0500, Felipe Contreras wrote:\n\n> > So in short, the color.pager is about \"is the pager capable of\n> > colors?\"\n> \n> That's not the case.\n> \n> Even the documentation says so:\n> \n> color.pager::\n> A boolean to enable/disable colored output when the pager is in\n> use (default is true).\n\nI think that documentation misses the reason you'd want to use it.\nLikewise, the commit message introducing it (aa086eb813d) sucks, but the\nmotivation (from [0]) was:\n\n When I use a pager that escapes the escape character or highlights the\n content itself the output of git diff without the pager should have\n colors but not with the pager. For example using git diff with a\n pathspec is quite short most of the time. For git diff I have to\n enable paging manually and run git diff | $PAGER usually but git log\n uses the pager automatically and should not use colors with it.\n\nFor a more concrete example, my pager _does_ understand colors, and I\nwould not want to set pager.color to \"false\" (because then \"git log\",\netc, would not show me any colors). But I don't like the man colors you\nare suggesting. I want to be able to turn them off by setting\n\"color.man\" or similar to false, not by disabling color for everything\nthat is paged.\n\nSo color.pager being true is _necessary_ for showing colors in paged\noutputs, but by itself is not sufficient. We have other per-context\ncolor options (color.diff, color.branch, and so on).\n\nAnd so likewise, we would want to avoid turning on colors if the user\nhas set color.pager=false. Usually this is done automatically because\nwant_color() checks, which knows if we are using the pager or not. But\nif we are going to call out to \"man\" which will invoke another pager,\nthat caller would have to check pager_use_color themselves (it's yet\nanother question of whether \"the pager can handle color\" applies equally\nto the pager that Git will run versus the one that man will run).\n\n-Peff\n\n[0] https://lore.kernel.org/git/E1G6zPH-00062L-Je@moooo.ath.cx/\n"},{"id":"424867","messageId":"60a3bf5624cbc_15198720876@natae.notmuch","threadId":"55699","inReplyTo":"YKNptH9DL6pe18Dk@coredump.intra.peff.net","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2021-05-18T13:21:26Z","receivedAt":"2021-05-18T13:21:31Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"Jeff King wrote:\n> On Mon, May 17, 2021 at 11:27:23PM -0500, Felipe Contreras wrote:\n> \n> > > So in short, the color.pager is about \"is the pager capable of\n> > > colors?\"\n> > \n> > That's not the case.\n> > \n> > Even the documentation says so:\n> > \n> > color.pager::\n> > A boolean to enable/disable colored output when the pager is in\n> > use (default is true).\n> \n> I think that documentation misses the reason you'd want to use it.\n> Likewise, the commit message introducing it (aa086eb813d) sucks,\n\nWell, it was 2006. Many of the best practices of today were not followed\nback then.\n\n> but the\n> motivation (from [0]) was:\n> \n> When I use a pager that escapes the escape character or highlights the\n> content itself the output of git diff without the pager should have\n> colors but not with the pager. For example using git diff with a\n> pathspec is quite short most of the time. For git diff I have to\n> enable paging manually and run git diff | $PAGER usually but git log\n> uses the pager automatically and should not use colors with it.\n\nThis is aligned with what I said: the uswer wants to disable colors when\nusing a pager.\n\nYes, in this instance it's because the pager doesn't support colors, but\nthat's not always necessarily so. A person with sight problems may use\nless (perfectly capable of colors), but yet not want to exercise that\ncapability.\n\nIt's still a preference.\n\n> For a more concrete example, my pager _does_ understand colors, and I\n> would not want to set pager.color to \"false\" (because then \"git log\",\n> etc, would not show me any colors). But I don't like the man colors you\n> are suggesting.\n\nYou can change them in your environment.\n\n> I want to be able to turn them off by setting \"color.man\" or similar\n> to false, not by disabling color for everything that is paged.\n\nSure, for that particular case it does make sense. I'll add that.\n\n> So color.pager being true is _necessary_ for showing colors in paged\n> outputs, but by itself is not sufficient. We have other per-context\n> color options (color.diff, color.branch, and so on).\n> \n> And so likewise, we would want to avoid turning on colors if the user\n> has set color.pager=false. Usually this is done automatically because\n> want_color() checks, which knows if we are using the pager or not. But\n> if we are going to call out to \"man\" which will invoke another pager,\n> that caller would have to check pager_use_color themselves (it's yet\n> another question of whether \"the pager can handle color\" applies equally\n> to the pager that Git will run versus the one that man will run).\n\nYes, but we still need to check pager_use_color.\n\nExcept... Maybe a user has GIT_PAGER set to a colorless pager, and\nMANPAGER to something fancier, in which case color.pager should be\nignored. But that's probably a corner-case nobody is ever going to hit.\n\nAnyway, I've sent an update version with color.man.\n\n-- \nFelipe Contreras\n"},{"id":"424878","messageId":"xmqqlf8c2k2y.fsf@gitster.g","threadId":"55699","inReplyTo":"YKNptH9DL6pe18Dk@coredump.intra.peff.net","subject":"Re: Man pages have colors? A deep dive into groff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2021-05-18T14:27:33Z","receivedAt":"2021-05-18T14:27:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, May 17, 2021 at 11:27:23PM -0500, Felipe Contreras wrote:\n>\n>> > So in short, the color.pager is about \"is the pager capable of\n>> > colors?\"\n>> \n>> That's not the case.\n>> \n>> Even the documentation says so:\n>> \n>> color.pager::\n>> A boolean to enable/disable colored output when the pager is in\n>> use (default is true).\n>\n> I think that documentation misses the reason you'd want to use it.\n\nThanks for digging and I agree that this one is quite bad---no\nwonder it misled to the \"why not color.pager?\" question.\n\nThe configuration is solely used to disable (because it defaults to\ntrue) colors when pager is in use and the configurations on the\napplication side (i.e. color.ui and friends) specify \"auto\". We\nshould update the description.\n\n> And so likewise, we would want to avoid turning on colors if the user\n> has set color.pager=false. Usually this is done automatically because\n> want_color() checks, which knows if we are using the pager or not.\n"}]}