From: Junio C Hamano <hidden> Date: 2021-05-19 06:09:39
"brian m. carlson" [off-list ref] writes:
On 2021-05-19 at 01:08:54, Junio C Hamano wrote:
quoted
"brian m. carlson" [off-list ref] writes:
quoted
In general, this is made worse because Git doesn't honor the unofficial
but widely supported NO_COLOR[0], so reading the documentation is
obligatory.
I vaguely recall that we were contacted by NO_COLOR folks to be
an early supporter of their cause to break the chicken-and-egg
problem they were hagving, and (unhelpfully) answered with "sure,
when we see enough people support it---otherwise we'd end up having
to keep essentially a dead code that supports a convention that is
not all that useful".
Yeah, I seem to recall you were somewhat negative on it at the time, but
I do personally find it useful, and someone on Twitter reminded me of
it just today.
quoted
I wonderr if it is just a matter of hooking into want_color(), like this?
color.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
@@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)*wealwayswritethesamevalue,butit'sstillwrong.Thisfunction*islistedin.tsan-suppressionsforthetimebeing.*/-+staticintno_color=-1;staticintwant_auto[3]={-1,-1,-1};if(fd<1||fd>=ARRAY_SIZE(want_auto))BUG("file descriptor out of range: %d",fd);+if(no_color<0)+no_color=!!getenv("NO_COLOR");+if(no_color)+return0;+if(var<0)var=git_use_color_default;
Yeah, that will probably do it. I hadn't looked at it, but I assumed it
would be pretty easy, and it looks like it is.
In general, this is made worse because Git doesn't honor the unofficial
but widely supported NO_COLOR[0], so reading the documentation is
obligatory.
I vaguely recall that we were contacted by NO_COLOR folks to be
an early supporter of their cause to break the chicken-and-egg
problem they were hagving, and (unhelpfully) answered with "sure,
when we see enough people support it---otherwise we'd end up having
to keep essentially a dead code that supports a convention that is
not all that useful".
Yeah, I seem to recall you were somewhat negative on it at the time, but
I do personally find it useful, and someone on Twitter reminded me of
it just today.
quoted
I wonderr if it is just a matter of hooking into want_color(), like this?
color.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
@@ -373,12 +373,17 @@ int want_color_fd(int fd, int var)*wealwayswritethesamevalue,butit'sstillwrong.Thisfunction*islistedin.tsan-suppressionsforthetimebeing.*/-+staticintno_color=-1;staticintwant_auto[3]={-1,-1,-1};if(fd<1||fd>=ARRAY_SIZE(want_auto))BUG("file descriptor out of range: %d",fd);+if(no_color<0)+no_color=!!getenv("NO_COLOR");+if(no_color)+return0;+if(var<0)var=git_use_color_default;
Yeah, that will probably do it. I hadn't looked at it, but I assumed it
would be pretty easy, and it looks like it is.
[CC'd the author of that proposal]
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'm not sure if it matters for git, the FAQ point isn't really clear on
what the distinction is exactly. Users who want to use color for say CLI
emacs/vim/screen/tmux "status" bars, but don't want any "normal" CLI
program to emit them?
But if we gained such a "status" bar feature the proposed 2018 patch
would be actively going against what NO_COLOR users want, since it's our
equivalent of TERM=dumb, not whatever NO_COLOR=1 is supposed to mean. Or
maybe we already have that, I would think that "git add -i"'s UI would
count.
It seems like it really should have been named MOSTLY_NOT_COLOR=1 or
ONLY_COLOR_NCURSES_LIKE_UIS=1 if I'm understanding that FAQ item
correctly.
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.
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.
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.
But it seems to me to just introduce even more confusion to the *nix
coloring landscape. For what it's apparently trying to accomplish I
think it would be a much better thing to:
1. Have terminals/startup rc'd etc. set a TERM_ACTUAL=<old value>
before setting TERM=dumb. This is something POSIX et al could
eventually standardize, i.e. "TERM=dumb" for now, but actually I
support "TERM=xyz".
2. Have some "color_this" shell function/alias/wrapper to start things
like your editor, which would just be a one-line wrapper to start
that program with TERM=$TERM_ACTUAL, or those programs would learn
to look at TERM_ACTUAL.
The user would thus get color almost nowhere in "normal" programs like
"git status" or "ls", but would get them in emacs, vim, screet, tmux,
htop or whatever other "big" terminal UI they run.
I.e. the whole point seems to be to support the use-case of wanting
color almost nowhere except a very small whitelist of programs, but
trying to accomplish it with NO_COLOR means that hundreds/thousands of
programs need to support it, as opposed to the much smaller list of
editors/terminal multiplexers etc.
Each of those programs then need to subjectively decide if their UI
elements are "such as [...] a status bar". If they get it wrong the user
is back to inovking them with TERM=dumb anyway.
From: Felipe Contreras <hidden> Date: 2021-05-19 10:36:37
Ævar Arnfjörð Bjarmason wrote:
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".
In my subjective opinion most of git uses color sensibly, so we kind of
already support NO_COLOR (turn it on, and you'd get sensible colors).
Except, my patch to colorize man pages can be considered to be coloring
things willy-nilly.
So perhaps that's the only instance where we should consider caring
about that.
Cheers.
--
Felipe Contreras
From: brian m. carlson <hidden> Date: 2021-05-21 00:58:29
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
From: Felipe Contreras <hidden> Date: 2021-05-21 18:09:20
brian m. carlson wrote:
On 2021-05-19 at 08:41:44, Ævar Arnfjörð Bjarmason wrote:
quoted
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.
The very example they give says otherwise:
It is reasonable to configure certain software such as a text editor
to use color
They are saying a text editor adding color is *fine*.
NO_COLOR=1 says, "I don't want color, but I have a fully functional
terminal I would like to use, thank you."
That's not what it says.
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.
That is a reasonable interpretation... until you read the next
answer:
A user should be able to export $NO_COLOR in their shell configuration
file as a default, but configure a specific program in its
configuration file to specifically enable color.
The whole point is not to configure each program to disable color, but
have a global NO_COLOR.
So I don't think your interpretation is correct.
--
Felipe Contreras
From: Igor Djordjevic <hidden> Date: 2021-05-21 19:48:36
Hi all,
If I may, NO_COLOR approach seems to be rather straightforward to me,
as per description on their homepage[1] - make all software supporting
it behave as colors are an opt-in feature, thus disabled by default.
And that's all there is to it.
Software which is able to but does not show any colors by default does
not need to care at all, as colors are an opt-in feature there already,
so NO_COLOR serves no purpose.
On the other hand, software which does enable (at least some) color
by default, without user explicitly setting anything but requiring
opt-out to disable color instead, should treat NO_COLOR precisely as
that user requested opt-out, with an obvious convenience for the user
being able to set NO_COLOR globally once and have all the programs
supporting it recognize it as color opt-out exactly, without a need
for the user to opt-out in each and every program separately
(and differently).
So, the whole point is make the default value be "no color" for each
and every application consistently, where user (and _not_ developer)
needs to opt-in in order to enable colors (in each and every
application where colors are in fact still desired).
Regards, Buga
--
[1]: https://no-color.org/
From: Felipe Contreras <hidden> Date: 2021-05-21 21:20:57
Igor Djordjevic wrote:
If I may, NO_COLOR approach seems to be rather straightforward to me,
as per description on their homepage[1] - make all software supporting
it behave as colors are an opt-in feature, thus disabled by default.
May I ask you how you interpret this?
It is reasonable to configure certain software such as a text editor
to use color ... sparingly
--
Felipe Contreras
From: Igor Djordjevic <hidden> Date: 2021-05-21 22:10:49
On 21/05/2021 23:20, Felipe Contreras wrote:
Igor Djordjevic wrote:
quoted
If I may, NO_COLOR approach seems to be rather straightforward to me,
as per description on their homepage[1] - make all software supporting
it behave as colors are an opt-in feature, thus disabled by default.
May I ask you how you interpret this?
It is reasonable to configure certain software such as a text editor
to use color ... sparingly
Sure, but to make the point (hopefully) even more obvious, let me
quote the whole part:
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.
I understand it exactly as (I think) it says - it is reasonable to
allow (the user, not developer!) to configure certain software to
(still) use color (fully or sparingly should not even matter, and it
may depend on what kind of granular configuration software allows in
the first place, if any), even if his (user's) general ("default")
preference is to have no colors.
Thus color should be user opt-in - NO_COLOR turns all of it off by
default (for all software supporting it), and user decides which color
to turn back on through each specific software color configuration.
That last sentence should make it clear - "it should be up to the
user whether color is used, not the software author".
So it shouldn't matter what does software author think about which
parts of software should be (fully or sparingly) colored (by default)
- NO_COLOR's idea is to give the ultimate power to the user to
decide, and on a global level, starting with no colors by default,
then allowing colors where desired, per each specific software config
(instead of vice-versa, being required to turn color off per each
specific software, where color is otherwise used by default).
At least that's how I understand all of it, making sense to me, but I
don't mind discussing it further, if needed.
From: Igor Djordjevic <hidden> Date: 2021-05-21 22:47:12
On 21/05/2021 21:48, Igor Djordjevic wrote:
So, the whole point is make the default value be "no color" for each
and every application consistently, where user (and _not_ developer)
needs to opt-in in order to enable colors (in each and every
application where colors are in fact still desired).
Oh, and might be what NO_COLOR homepage provides as a tip for
"disabling color in software not supporting NO_COLOR" for Git
specifically might be a good (and enough of a) clue by itself...?
git config --global color.ui false
So I'd argue that Git should react to NO_COLOR exactly as it should
react to `color.ui` set to false - disabling all color.
Do note it's only by default, in case no (other) color configuration is
specified - any existing user config should take precedence, of course,
further acting as per user's desire ("... NO_COLOR says I prefer no
color in general, but I do want color in this specific case, enabled by
setting this software specific config option explicitly...").
From: Felipe Contreras <hidden> Date: 2021-05-21 23:04:34
Igor Djordjevic wrote:
On 21/05/2021 23:20, Felipe Contreras wrote:
quoted
Igor Djordjevic wrote:
quoted
If I may, NO_COLOR approach seems to be rather straightforward to me,
as per description on their homepage[1] - make all software supporting
it behave as colors are an opt-in feature, thus disabled by default.
May I ask you how you interpret this?
It is reasonable to configure certain software such as a text editor
to use color ... sparingly
Sure, but to make the point (hopefully) even more obvious, let me
quote the whole part:
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.
I understand it exactly as (I think) it says - it is reasonable to
allow (the user, not developer!) to configure certain software to
(still) use color
This does not follow.
The contraposition of that statement is that if a text editor doesn't
use color sparingly, then the user should not be allowed to configure
such software.
Do you really think that's what they are saying? The user should not
have a choice? (with certain software) That's color fascism.
--
Felipe Contreras
From: Igor Djordjevic <hidden> Date: 2021-05-22 18:38:47
On 22/05/2021 01:04, Felipe Contreras wrote:
Igor Djordjevic wrote:
quoted
... to make the point (hopefully) even more obvious, let me
quote the whole part:
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.
I understand it exactly as (I think) it says - it is reasonable to
allow (the user, not developer!) to configure certain software to
(still) use color
This does not follow.
Sure, if that is the only part you read ("followed"), taking it out
of context while chopping the rest...
The contraposition of that statement is that if a text editor doesn't
use color sparingly, then the user should not be allowed to configure
such software.
Do you really think that's what they are saying? The user should not
have a choice? (with certain software) That's color fascism.
What I really think is that my message which you replied to - but
decided to quote only _sparingly_ ;) - already addressed both use of
"sparingly" and who should have the choice (not to say all the power)
in a very clear and explicit manner (hint: user exactly), so I'm afraid
I'd have nothing more to add, sorry.
Regards, Buga
p.s. Oh, and please do allow me to _opt-in_ the missing part of my
message back :) (for whatever that will be worth, eh):
quoted
I understand it exactly as (I think) it says - it is reasonable to
allow (the user, not developer!) to configure certain software to
(still) use color (fully or sparingly should not even matter, and it
may depend on what kind of granular configuration software allows in
the first place, if any), even if his (user's) general ("default")
preference is to have no colors.
Thus color should be user opt-in - NO_COLOR turns all of it off by
default (for all software supporting it), and user decides which color
to turn back on through each specific software color configuration.
That last sentence should make it clear - "it should be up to the
user whether color is used, not the software author".
So it shouldn't matter what does software author think about which
parts of software should be (fully or sparingly) colored (by default)
- NO_COLOR's idea is to give the ultimate power to the user to
decide, and on a global level, starting with no colors by default,
then allowing colors where desired, per each specific software config
(instead of vice-versa, being required to turn color off per each
specific software, where color is otherwise used by default).
From: Felipe Contreras <hidden> Date: 2021-05-22 21:48:08
Igor Djordjevic wrote:
On 22/05/2021 01:04, Felipe Contreras wrote:
quoted
Igor Djordjevic wrote:
quoted
... to make the point (hopefully) even more obvious, let me
quote the whole part:
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.
I understand it exactly as (I think) it says - it is reasonable to
allow (the user, not developer!) to configure certain software to
(still) use color
This does not follow.
Sure, if that is the only part you read ("followed"), taking it out
of context while chopping the rest...
Language is understood bit by bit. To properly understand the sentences
that follow you first need to understand the sentences that preceed.
quoted
The contraposition of that statement is that if a text editor doesn't
use color sparingly, then the user should not be allowed to configure
such software.
Do you really think that's what they are saying? The user should not
have a choice? (with certain software) That's color fascism.
What I really think is that my message which you replied to - but
decided to quote only _sparingly_ ;) - already addressed both use of
"sparingly" and who should have the choice (not to say all the power)
in a very clear and explicit manner (hint: user exactly), so I'm afraid
I'd have nothing more to add, sorry.
I know what you said in the rest of the message, which is precisely why
it does not follow, and since you ignored my argument, let me state it
with logic symbols for the record.
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)
We extract part of the message:
It is reasonable to configure a text editor to use color sparingly
The first sentence implies the second, no information is changed.
---
You interpret that as:
It is reasonable to allow the user to configure a text editor to use
color sparingly
This is obviously a different sentence. You introduced a part that was
not there.
Now we use logic symbols to transform your sentence:
p = the user configures a text editor to use color sparingly
q = it is reasonable to allow the user
This is what you said: if p -> q. The contraposition is: ~q -> ~p.
Therefore you said:
It is not reasonable to allow the user to configure a text editor to
not use color sparingly.
This is a fact.
What you said doesn't make sense.
---
This what no-color.org said:
It is reasonable to configure a text editor to use color sparingly
By doing the same contraposition as above we get that it's the same as:
It is not reasonale to configure a text editor to not use color
sparingly.
Or in other words.
It is not reasonable to configure a text editor to use colors heavily.
If it's the developers doing that, then that statement is correct.
This is my interpretation. My interpretation holds to scrutiny; yours
does not.
They meant the developers. They are not trying to tell users what to do.
Cheers.
--
Felipe Contreras
From: Igor Djordjevic <hidden> Date: 2021-05-23 11:26:12
On 22/05/2021 23:48, Felipe Contreras wrote:
Language is understood bit by bit. To properly understand the sentences
that follow you first need to understand the sentences that preceed.
Except you can't deliberately chop and butcher mentioned sentences in
order to "understand" them in isolation, as the meaning is largely
determined by context - and yes, the following sentences as well.
You focus on seeing the trees, but you're missing the forest.
I know what you said in the rest of the message, which is precisely why
it does not follow, and since you ignored my argument, let me state it
with logic symbols for the record.
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)
We extract part of the message:
It is reasonable to configure a text editor to use color sparingly
The first sentence implies the second, no information is changed.
---
You interpret that as:
It is reasonable to allow the user to configure a text editor to use
color sparingly
This is obviously a different sentence. You introduced a part that was
not there.
Now we use logic symbols to transform your sentence:
p = the user configures a text editor to use color sparingly
q = it is reasonable to allow the user
This is what you said: if p -> q. The contraposition is: ~q -> ~p.
Therefore you said:
It is not reasonable to allow the user to configure a text editor to
not use color sparingly.
This is a fact.
What you said doesn't make sense.
---
This what no-color.org said:
It is reasonable to configure a text editor to use color sparingly
By doing the same contraposition as above we get that it's the same as:
It is not reasonale to configure a text editor to not use color
sparingly.
Or in other words.
It is not reasonable to configure a text editor to use colors heavily.
If it's the developers doing that, then that statement is correct.
This is my interpretation. My interpretation holds to scrutiny; yours
does not.
They meant the developers. They are not trying to tell users what to do.
Cheers.
You are overthinking the whole thing (or the piece(s) you focused on, in
fact missing the thing as a whole completely), making it unnecessarily
complicated for yourself.
The NO_COLOR[1] homepage text, read in its entirety and even if not
perfect, seems clear enough for everyone who wants to understand it.
I'm sorry if it's not clear for you, I'm afraid I can't help any
further.
And while I find your armchair analysis amusing, you'll pardon me for
not taking any more part in it as, unfortunately, I don't have that
much time at my hands to waste.
Cheers, Buga
--
[1]: https://no-color.org/
From: Felipe Contreras <hidden> Date: 2021-05-23 14:48:45
Igor Djordjevic wrote:
On 22/05/2021 23:48, Felipe Contreras wrote:
quoted
Language is understood bit by bit. To properly understand the sentences
that follow you first need to understand the sentences that preceed.
Except you can't deliberately chop and butcher mentioned sentences in
order to "understand" them in isolation, as the meaning is largely
determined by context - and yes, the following sentences as well.
Please explain the context that makes this sentense makes ense:
It is not reasonable to allow the user to configure a text editor to
not use color heavily.
The NO_COLOR[1] homepage text, read in its entirety and even if not
perfect, seems clear enough for everyone who wants to understand it.
Yes, it is clear: software who use colors heavily should respect
NO_COLOR.
Others on this list agree.
--
Felipe Contreras