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