From: Junio C Hamano <hidden> Date: 2021-05-21 05:06:54
Phillip Wood [off-list ref] writes:
On 20/05/2021 05:07, Felipe Contreras wrote:
quoted
We already colorize tools traditionally not colorized by default, like
diff and grep. Let's do the same for man.
I think there is a distinction between 'diff' and 'grep' where we are
generating the content and help where we are running man - I would
expect a man page to look the same whether it is displayed by 'man git
foo' or 'git help foo'
... as long as the user chooses "man" backend, that is. And I tend
to agree, but that is our expectation.
If we added this new mode of driving the same "man" but with
different environment variables exported to tweak how "less"
behaves, and taught it to builtin/help.c::exec_viewer() and
builtin/help.c::man_viewer_list, that might become more palatable in
the sense that we can view it as feeding the same manual page to
this another "man" that behaves differently from the plain "man",
just like we can feed it to "woman" or "konqueror" to get a different
view. So those (like you and I) who expect a man page to look the
same in "man git foo" and "git help -m foo" can keep using our current
configuration, while those who want yet another variant of "man" output
in addition to the current "man", "woman", and "konqueror" can choose
it and get "colorized" output.
By the way, this new round mentions NO_COLOR, and while I think it
is good idea to teach git to honor it, I think it does it at a wrong
level. Each ui driver that is optionally capable of coloring its
output shouldn't have to care, and the right level is either inside
want_color() or its helper function check_auto_color(), both in
color.c, to say "the user hasn't configured the output of this
subcommand for coloring, and by default we use color under certain
conditions (i.e. "auto"), but we decide not to use color because
NO_COLOR environment is set before even checking these "auto"
conditions.
From: Jeff King <hidden> Date: 2021-05-21 08:44:28
On Fri, May 21, 2021 at 02:06:48PM +0900, Junio C Hamano wrote:
Phillip Wood [off-list ref] writes:
quoted
On 20/05/2021 05:07, Felipe Contreras wrote:
quoted
We already colorize tools traditionally not colorized by default, like
diff and grep. Let's do the same for man.
I think there is a distinction between 'diff' and 'grep' where we are
generating the content and help where we are running man - I would
expect a man page to look the same whether it is displayed by 'man git
foo' or 'git help foo'
... as long as the user chooses "man" backend, that is. And I tend
to agree, but that is our expectation.
If we added this new mode of driving the same "man" but with
different environment variables exported to tweak how "less"
behaves, and taught it to builtin/help.c::exec_viewer() and
builtin/help.c::man_viewer_list, that might become more palatable in
the sense that we can view it as feeding the same manual page to
this another "man" that behaves differently from the plain "man",
just like we can feed it to "woman" or "konqueror" to get a different
view. So those (like you and I) who expect a man page to look the
same in "man git foo" and "git help -m foo" can keep using our current
configuration, while those who want yet another variant of "man" output
in addition to the current "man", "woman", and "konqueror" can choose
it and get "colorized" output.
I still don't understand what we gain by making this a Git feature, as
all of the changed behavior is totally within the program we are
calling. Imagine that konqueror (or an html viewer like firefox) had an
option to set its color scheme from the command line. Should we
introduce a new baked-in fancy-konqueror backend that is "run the tool
with a tweaked color scheme"?
Why would we do that versus saying: if you want to change the colors in
the tool that Git calls, then configure the tool?
If you like to see colors in manpages, why not configure "man" (either
by setting these environment variables all the time, or by triggering
them in MANPAGER)? And then Git doesn't have to care either way; it is
calling "man" which does what the user wants, colors or no. If you
really for some reason only want colorized man pages when called via
"git help", then why not set man.fancy.cmd to invoke your preferred
config?
If those configurations are awkward to trigger via man (e.g., putting
escapes into termcap variables), isn't that something that could be
improved in man? And then it would benefit everyone who uses man, not
just Git.
-Peff
From: Felipe Contreras <hidden> Date: 2021-05-21 17:54:37
Junio C Hamano wrote:
Phillip Wood [off-list ref] writes:
quoted
On 20/05/2021 05:07, Felipe Contreras wrote:
quoted
We already colorize tools traditionally not colorized by default, like
diff and grep. Let's do the same for man.
I think there is a distinction between 'diff' and 'grep' where we are
generating the content and help where we are running man - I would
expect a man page to look the same whether it is displayed by 'man git
foo' or 'git help foo'
... as long as the user chooses "man" backend, that is. And I tend
to agree, but that is our expectation.
If we added this new mode of driving the same "man" but with
different environment variables exported to tweak how "less"
behaves, and taught it to builtin/help.c::exec_viewer() and
builtin/help.c::man_viewer_list, that might become more palatable in
the sense that we can view it as feeding the same manual page to
this another "man" that behaves differently from the plain "man",
just like we can feed it to "woman" or "konqueror" to get a different
view. So those (like you and I) who expect a man page to look the
same in "man git foo" and "git help -m foo" can keep using our current
configuration, while those who want yet another variant of "man" output
in addition to the current "man", "woman", and "konqueror" can choose
it and get "colorized" output.
So... "mancolor"?
By the way, this new round mentions NO_COLOR, and while I think it
is good idea to teach git to honor it, I think it does it at a wrong
level.
Other people have already mentioend the FAQ [1]:
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.
At whatever level it's chosen it shouldn't blatantly disable all color.
Each ui driver that is optionally capable of coloring its
output shouldn't have to care,
But they do have to care. The purpose of NO_COLOR is not to disable all
color, but to disable annoying color.
https://no-color.org/
--
Felipe Contreras
From: Felipe Contreras <hidden> Date: 2021-05-21 18:01:40
Jeff King wrote:
On Fri, May 21, 2021 at 02:06:48PM +0900, Junio C Hamano wrote:
quoted
Phillip Wood [off-list ref] writes:
quoted
On 20/05/2021 05:07, Felipe Contreras wrote:
quoted
We already colorize tools traditionally not colorized by default, like
diff and grep. Let's do the same for man.
I think there is a distinction between 'diff' and 'grep' where we are
generating the content and help where we are running man - I would
expect a man page to look the same whether it is displayed by 'man git
foo' or 'git help foo'
... as long as the user chooses "man" backend, that is. And I tend
to agree, but that is our expectation.
If we added this new mode of driving the same "man" but with
different environment variables exported to tweak how "less"
behaves, and taught it to builtin/help.c::exec_viewer() and
builtin/help.c::man_viewer_list, that might become more palatable in
the sense that we can view it as feeding the same manual page to
this another "man" that behaves differently from the plain "man",
just like we can feed it to "woman" or "konqueror" to get a different
view. So those (like you and I) who expect a man page to look the
same in "man git foo" and "git help -m foo" can keep using our current
configuration, while those who want yet another variant of "man" output
in addition to the current "man", "woman", and "konqueror" can choose
it and get "colorized" output.
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Why would we do that versus saying: if you want to change the colors in
the tool that Git calls, then configure the tool?
Once again... How?
If you like to see colors in manpages, why not configure "man" (either
by setting these environment variables all the time, or by triggering
them in MANPAGER)?
Let me try that...
MANPAGER="less -Dd+r -Du+b -Ds+m" git help git
It doesn't work.
If those configurations are awkward to trigger via man (e.g., putting
escapes into termcap variables), isn't that something that could be
improved in man? And then it would benefit everyone who uses man, not
just Git.
Sure. In the meantime let's make `git help` output with color just like
`git diff`.
Cheers.
(and good luck convincing a GNU project of anything)
--
Felipe Contreras
From: Jeff King <hidden> Date: 2021-05-21 20:26:07
On Fri, May 21, 2021 at 01:01:35PM -0500, Felipe Contreras wrote:
quoted
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Huh? Git is outputting the diff. Who else would output the color?
quoted
Why would we do that versus saying: if you want to change the colors in
the tool that Git calls, then configure the tool?
Once again... How?
By exporting the environment variables that ask it to do so, just like
you showed already?
quoted
If you like to see colors in manpages, why not configure "man" (either
by setting these environment variables all the time, or by triggering
them in MANPAGER)?
Let me try that...
MANPAGER="less -Dd+r -Du+b -Ds+m" git help git
It doesn't work.
ESC=$(printf '\33')
export MANCOLORS="LESS_TERMCAP_md=$ESC[31m LESS_TERMCAP_me=$ESC[0m"
export MANPAGER='sh -c "eval $MANCOLORS less"'
man ls
git help git
At least on Linux, $MANPAGER is some weird limbo that is not run with
the shell, but not just a simple command. Hence the extra layer of "sh".
If I were actually planning to use this myself, I'd probably put it in a
"manpager" script in my $PATH and just do MANPAGER=manpager.
-Peff
From: Felipe Contreras <hidden> Date: 2021-05-21 21:40:40
Jeff King wrote:
On Fri, May 21, 2021 at 01:01:35PM -0500, Felipe Contreras wrote:
quoted
quoted
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Huh? Git is outputting the diff. Who else would output the color?
Do you think our users know or care which binary has the final
connection to the tty?
Many probably think git is sending the output to `diff --color -u`, and
it doesn't matter at all.
quoted
quoted
Why would we do that versus saying: if you want to change the colors in
the tool that Git calls, then configure the tool?
Once again... How?
By exporting the environment variables that ask it to do so, just like
you showed already?
Exporting MANPAGER is not enough. That would only work on systems that
have SGR disabled.
The user would have to in addition export GROFF_NO_SGR=1, but that would
disble groff color for everything, which may not be what the user wants.
There is no MANGROFFNOSGR.
quoted
quoted
If you like to see colors in manpages, why not configure "man" (either
by setting these environment variables all the time, or by triggering
them in MANPAGER)?
Let me try that...
MANPAGER="less -Dd+r -Du+b -Ds+m" git help git
It doesn't work.
ESC=$(printf '\33')
export MANCOLORS="LESS_TERMCAP_md=$ESC[31m LESS_TERMCAP_me=$ESC[0m"
export MANPAGER='sh -c "eval $MANCOLORS less"'
man ls
git help git
That still doesn't work here.
https://snipboard.io/GmhRtU.jpg
I see the default docbook colos generated by groff, but not the ones you
specified (both on `man` and `git help`).
I need to do this as well:
export GROFF_NO_SGR=1
Your system probably has groff's SGR disabled in /usr/share/groff/site-tmac/man.local
It's not that simple.
There is in fact a way to configure man to do what we want here but if
*nobody* knows what that way is, then does it really matter?
Cheers.
--
Felipe Contreras
From: Jeff King <hidden> Date: 2021-05-22 09:55:12
On Fri, May 21, 2021 at 04:40:30PM -0500, Felipe Contreras wrote:
Jeff King wrote:
quoted
On Fri, May 21, 2021 at 01:01:35PM -0500, Felipe Contreras wrote:
quoted
quoted
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Huh? Git is outputting the diff. Who else would output the color?
Do you think our users know or care which binary has the final
connection to the tty?
Yes. If we are telling them that "git help git" is using "man", which we
do, then I think they should expect it to behave like "man".
Moreover, I think that if they like colorized manpages, they'd probably
want them when running "man" themselves.
-Peff
From: Philip Oakley <hidden> Date: 2021-05-22 12:43:52
On 22/05/2021 10:55, Jeff King wrote:
On Fri, May 21, 2021 at 04:40:30PM -0500, Felipe Contreras wrote:
quoted
Jeff King wrote:
quoted
On Fri, May 21, 2021 at 01:01:35PM -0500, Felipe Contreras wrote:
quoted
quoted
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Huh? Git is outputting the diff. Who else would output the color?
Do you think our users know or care which binary has the final
connection to the tty?
Yes. If we are telling them that "git help git" is using "man", which we
do, then I think they should expect it to behave like "man".
Moreover, I think that if they like colorized manpages, they'd probably
want them when running "man" themselves.
-Peff
And we have the whole Git for Windows community who don't have `man`
anyway...
It's a bit of a conundrum, especially when considering all the
'terminals' Windows folk maybe using.
From: Felipe Contreras <hidden> Date: 2021-05-22 20:51:56
Jeff King wrote:
On Fri, May 21, 2021 at 04:40:30PM -0500, Felipe Contreras wrote:
quoted
Jeff King wrote:
quoted
On Fri, May 21, 2021 at 01:01:35PM -0500, Felipe Contreras wrote:
quoted
quoted
I still don't understand what we gain by making this a Git feature,
What do we gain by making `git diff` output color?
Huh? Git is outputting the diff. Who else would output the color?
Do you think our users know or care which binary has the final
connection to the tty?
Yes. If we are telling them that "git help git" is using "man", which we
do, then I think they should expect it to behave like "man".
But we are not telling them.
Software is not in the business of explaining users exactly what it is
doing. Software is in the business of being useful to users, and in
order to do that it must remain as silent as possible while achieving
what the user potentially wants.
Unless we throw an advice("this command runs man"), then we are not
telling them.
If a dilligent user does `git help help` they might learn about this
fact, but we didn't tell them, they found out.
Moreover, I think that if they like colorized manpages, they'd probably
want them when running "man" themselves.
This doesn't matter.
The user might have "configured" man like this:
man() {
LESS_TERMCAP_md=$'\e[01;31m' \
LESS_TERMCAP_me=$'\e[0m' \
LESS_TERMCAP_so=$'\e[01;44;33m' \
LESS_TERMCAP_se=$'\e[0m' \
LESS_TERMCAP_us=$'\e[01;32m' \
LESS_TERMCAP_ue=$'\e[0m' \
command man "$@"
}
Git isn't going utilize that.
Arch Linux recommends the above, and so does many online resources.
So even if it's the case what you said, that they want colorized man
pages, *and* they have man configured, that doesn't matter.
In addition, not everyone is a Linux guru. Some might want colorized man
pages, but not know how to get them.
I myself only learned it was possible to configure that about a year ago
when reading Arch Linux's installation guide. Luckily I clicked "Color
output in console", even though I thought I already had most console
software configured.
I have 20 years of experience using Linux. Some people have less.
You presume too much of our users.
And you still haven't explained how they can properly configure
colorized man pages for both man and git, in a way that works in all
distributions.
[1] https://wiki.archlinux.org/title/Color_output_in_console
--
Felipe Contreras