From: "brian m. carlson" <firstname.lastname@example.org> To: "Ævar Arnfjörð Bjarmason" <email@example.com> Cc: Junio C Hamano <firstname.lastname@example.org>, Felipe Contreras <email@example.com>, firstname.lastname@example.org, "Randall S. Becker" <email@example.com>, Leah Neukirchen <firstname.lastname@example.org> Subject: Re: [PATCH] help: colorize man pages Date: Fri, 21 May 2021 00:58:21 +0000 [thread overview] Message-ID: <YKcFrbuuJrWAxXgm@camp.crustytoothpaste.net> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2980 bytes --] On 2021-05-19 at 08:41:44, Ævar Arnfjörð Bjarmason wrote: > It also doesn't seem to me to satisfy their FAQ point #1, i.e. users who > actually want no color at all can just set TERM=dumb, and we support > that. The proposed patch is the same as having TERM=dumb set. > > This NO_COLOR=1 actually means something like "I do support colors, so > show them if it's important, but don't color things willy-nilly". I don't agree. The way I read it is that it means that if your program receives colored input, it is not obligated to strip it out, but it is obligated not to add any. For example, if less supported NO_COLOR, then it would render color it received on stdin, but not color its status bars. For Git, this means that we shouldn't add color, but if a user has stuffed some ANSI escape sequences in their formatting string, we'll pass them through. > So it would be incorrect to map it to either color.ui=never or > color.ui=always (as "auto" will implicitly do). We'd need a new knob to > control the granularity of coloring, something like > color.ui=conservative. No, I think in the context of Git it means, "I don't want color." > I wasn't against NO_COLOR before, but after writing the above I think I > am. I initially assumed that it was some redundant and more "friendly" > way of setting TERM=dumb, but rather it's some entirely subjective way > for every program to decide if their UI elements are "text-editor"-like > or "status bar"-like enough to warrant coloring. TERM=dumb turns off having an addressable cursor. Git uses a pager for a lot of output, so that's a completely undesirable way to indicate you don't want color, since it makes scrolling backwards impossible (and may even disable the pager, but I haven't checked). For a text editor, TERM=dumb means you're stuck with ex or ed. NO_COLOR=1 says, "I don't want color, but I have a fully functional terminal I would like to use, thank you." I should point out that I think you've misread the text about status bars. It says this: It is reasonable to configure certain software such as a text editor to use color or other ANSI attributes sparingly (such as the reverse attribute for a status bar) while still desiring that other software not add color unless configured to. It should be up to the user whether color is used, not the software author. In other words, I think in this case, the user has opted to configure their editor as they like it and invoke it without NO_COLOR, but has instructed other programs to not add color with NO_COLOR. Note also that the explanation specifically mentions the reverse attribute, which TERM=dumb will suppress. > That's "against" in the sense that if git supported it I wouldn't care > much, and wouldn't oppose a patch to implement it. I will probably send a patch to implement it, just not tonight. -- brian m. carlson (he/him or they/them) Houston, Texas, US [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2021-05-21 0:58 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-18 1:01 Felipe Contreras 2021-05-18 1:19 ` brian m. carlson 2021-05-18 3:22 ` Felipe Contreras 2021-05-18 23:49 ` brian m. carlson 2021-05-19 1:08 ` Junio C Hamano 2021-05-19 2:07 ` brian m. carlson 2021-05-19 6:09 ` Junio C Hamano 2021-05-19 8:41 ` Ævar Arnfjörð Bjarmason 2021-05-19 10:36 ` Felipe Contreras 2021-05-21 0:58 ` brian m. carlson [this message] 2021-05-21 18:09 ` Felipe Contreras 2021-05-21 19:48 ` Igor Djordjevic 2021-05-21 21:20 ` Felipe Contreras 2021-05-21 22:10 ` Igor Djordjevic 2021-05-21 23:04 ` Felipe Contreras 2021-05-22 18:38 ` Igor Djordjevic 2021-05-22 21:48 ` Felipe Contreras 2021-05-23 11:25 ` Igor Djordjevic 2021-05-23 14:48 ` Felipe Contreras 2021-05-21 22:47 ` Igor Djordjevic 2021-05-21 23:32 ` Junio C Hamano 2021-05-19 9:26 ` Ævar Arnfjörð Bjarmason 2021-05-19 10:10 ` Jeff King 2021-05-19 11:45 ` Felipe Contreras 2021-05-19 11:19 ` Felipe Contreras 2021-05-19 12:21 ` Felipe Contreras 2021-05-20 1:55 ` brian m. carlson 2021-05-20 2:23 ` Junio C Hamano 2021-05-20 3:05 ` Felipe Contreras 2021-05-20 3:28 ` Junio C Hamano 2021-05-20 3:48 ` Felipe Contreras 2021-05-20 2:45 ` Felipe Contreras 2021-05-19 10:25 ` Felipe Contreras
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YKcFrbuuJrWAxXgm@camp.crustytoothpaste.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] help: colorize man pages' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).