git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org, "Randall S. Becker" <rsbecker@nexbridge.com>,
	Leah Neukirchen <leah@vuxu.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: <87lf8bqdv0.fsf@evledraar.gmail.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 --]

  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 [PATCH] help: colorize man pages 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

  List information: http://vger.kernel.org/majordomo-info.html

* 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 \
    --to=sandals@crustytoothpaste.net \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leah@vuxu.org \
    --cc=rsbecker@nexbridge.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).