From: Felipe Contreras <hidden> Date: 2021-06-08 17:51:12
It has been suggested that we "educate our users" to configure less in
the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
Felipe Contreras wrote:
Jeff King wrote:
quoted
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
From: Felipe Contreras <hidden> Date: 2021-06-28 18:11:54
Felipe Contreras wrote:
It has been suggested that we "educate our users" to configure less in
the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and git in a
way that works in all distributions?
No response.
It's safe to say at this point that nobody knows what that configuration
would look like.
So we cannot "educate our users" to do something that doesn't exist.
--
Felipe Contreras
From: Randall S. Becker <hidden> Date: 2021-06-28 18:46:59
On June 28, 2021 2:12 PM, Felipe Contreras wrote:
Felipe Contreras wrote:
quoted
It has been suggested that we "educate our users" to configure less in
the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
quoted
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and git in
a way that works in all distributions?
No response.
I think you're looking for something does not exist because it is platform and environment dependent. There are two ways to configure git to work with 'less' on NonStop and neither is identical to Ubuntu or Windows. Don't even get me started on what less does in a TSO/ISPF environment where everything is some single colour on black unless your emulator supports 3279 emulation.
It's safe to say at this point that nobody knows what that configuration would look like.
Nobody, perhaps, knows how to do this on every platform in the known universe 😊. There is no "one way" to do this consistently everywhere.
In addition, there are many different terminal emulators that end up interacting with git and many do not support vt220 colours. So again, I'm not really sure what can be done.
-Randall
From: Felipe Contreras <hidden> Date: 2021-06-28 19:01:38
Randall S. Becker wrote:
On June 28, 2021 2:12 PM, Felipe Contreras wrote:
quoted
Felipe Contreras wrote:
quoted
It has been suggested that we "educate our users" to configure less in
the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
quoted
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and git in
a way that works in all distributions?
No response.
I think you're looking for something does not exist because it is
platform and environment dependent.
Yes, but there's always some common denominator.
There are two ways to configure git to work with 'less' on NonStop and
neither is identical to Ubuntu or Windows.
But I'm not talking about configuring git to work with less.
Once you have less configured, how do you add colors? For example how do
you turn bold into red bold?
Don't even get me started on what less does in a TSO/ISPF environment
where everything is some single colour on black unless your emulator
supports 3279 emulation.
Is it even possible to add color there? I'm talking about platforms
where color is possible in the first place.
quoted
It's safe to say at this point that nobody knows what that configuration would look like.
Nobody, perhaps, knows how to do this on every platform in the known
universe 😊. There is no "one way" to do this consistently everywhere.
In the platforms where color is supported, and you have less, what does
this do?
LESS_TERMCAP_md=$'\e[1;31m' LESS_TERMCAP_me=$'\e[m' git help git
(I'm using a bashism, so you probably need bash for the example)
In addition, there are many different terminal emulators that end up
interacting with git and many do not support vt220 colours. So again,
I'm not really sure what can be done.
Obviously I meant in the platforms where it can be done.
How does the user properly colorize man pages for both man and git when
using less in a way that works in all distributions that support colors?
--
Felipe Contreras
From: Randall S. Becker <hidden> Date: 2021-06-28 19:34:53
On June 28, 2021 3:02 PM, Felipe Contreras wrote:
Randall S. Becker wrote:
quoted
On June 28, 2021 2:12 PM, Felipe Contreras wrote:
quoted
Felipe Contreras wrote:
quoted
It has been suggested that we "educate our users" to configure less
in the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
quoted
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and git
in a way that works in all distributions?
No response.
I think you're looking for something does not exist because it is
platform and environment dependent.
Yes, but there's always some common denominator.
quoted
There are two ways to configure git to work with 'less' on NonStop and
neither is identical to Ubuntu or Windows.
But I'm not talking about configuring git to work with less.
Once you have less configured, how do you add colors? For example how do you turn bold into red bold?
quoted
Don't even get me started on what less does in a TSO/ISPF environment
where everything is some single colour on black unless your emulator
supports 3279 emulation.
Is it even possible to add color there? I'm talking about platforms where color is possible in the first place.
quoted
quoted
It's safe to say at this point that nobody knows what that configuration would look like.
Nobody, perhaps, knows how to do this on every platform in the known
universe 😊. There is no "one way" to do this consistently everywhere.
In the platforms where color is supported, and you have less, what does this do?
LESS_TERMCAP_md=$'\e[1;31m' LESS_TERMCAP_me=$'\e[m' git help git
This only works in bash/shell. So if you are not initiating from a shell, you cannot use this technique.
From: Felipe Contreras <hidden> Date: 2021-06-28 19:44:28
Randall S. Becker wrote:
On June 28, 2021 3:02 PM, Felipe Contreras wrote:
quoted
Randall S. Becker wrote:
quoted
On June 28, 2021 2:12 PM, Felipe Contreras wrote:
quoted
Felipe Contreras wrote:
quoted
It has been suggested that we "educate our users" to configure less
in the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
quoted
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and git
in a way that works in all distributions?
No response.
I think you're looking for something does not exist because it is
platform and environment dependent.
Yes, but there's always some common denominator.
quoted
There are two ways to configure git to work with 'less' on NonStop and
neither is identical to Ubuntu or Windows.
But I'm not talking about configuring git to work with less.
Once you have less configured, how do you add colors? For example how do you turn bold into red bold?
quoted
Don't even get me started on what less does in a TSO/ISPF environment
where everything is some single colour on black unless your emulator
supports 3279 emulation.
Is it even possible to add color there? I'm talking about platforms where color is possible in the first place.
quoted
quoted
It's safe to say at this point that nobody knows what that configuration would look like.
Nobody, perhaps, knows how to do this on every platform in the known
universe 😊. There is no "one way" to do this consistently everywhere.
In the platforms where color is supported, and you have less, what does this do?
LESS_TERMCAP_md=$'\e[1;31m' LESS_TERMCAP_me=$'\e[m' git help git
This only works in bash/shell. So if you are not initiating from a shell, you cannot use this technique.
I know. The technique is not the point. You can use whatever technique
you want to get LESS_TERMCAP_md and LESS_TERMCAP_me set on the
environment before launching `git help git` in whatever way you want.
Now, clearly that technique would vary platform by platform, which is
precisely why I'm proposing to do it inside `git help` itself [1].
Clearly this would work on every platform that has less and color and
it's technique-independent:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
Would it not?
[1] https://lore.kernel.org/git/20210626025040.104428-1-felipe.contreras@gmail.com/
--
Felipe Contreras
From: Randall S. Becker <hidden> Date: 2021-06-28 19:58:40
On June 28, 2021 3:44 PM, Felipe Contreras wrote:
Randall S. Becker wrote:
quoted
On June 28, 2021 3:02 PM, Felipe Contreras wrote:
quoted
Randall S. Becker wrote:
quoted
On June 28, 2021 2:12 PM, Felipe Contreras wrote:
quoted
Felipe Contreras wrote:
quoted
It has been suggested that we "educate our users" to configure
less in the right way, instead of colorizing man pages ourselves [1].
The question is *how*? Nobody has answered that.
This is a continuation of the thread below.
quoted
I am still waiting for an explanation.
How does the user properly colorize man pages for both man and
git in a way that works in all distributions?
No response.
I think you're looking for something does not exist because it is
platform and environment dependent.
Yes, but there's always some common denominator.
quoted
There are two ways to configure git to work with 'less' on NonStop
and neither is identical to Ubuntu or Windows.
But I'm not talking about configuring git to work with less.
Once you have less configured, how do you add colors? For example how do you turn bold into red bold?
quoted
Don't even get me started on what less does in a TSO/ISPF
environment where everything is some single colour on black unless
your emulator supports 3279 emulation.
Is it even possible to add color there? I'm talking about platforms where color is possible in the first place.
quoted
quoted
It's safe to say at this point that nobody knows what that configuration would look like.
Nobody, perhaps, knows how to do this on every platform in the
known universe 😊. There is no "one way" to do this consistently everywhere.
In the platforms where color is supported, and you have less, what does this do?
LESS_TERMCAP_md=$'\e[1;31m' LESS_TERMCAP_me=$'\e[m' git help git
This only works in bash/shell. So if you are not initiating from a shell, you cannot use this technique.
I know. The technique is not the point. You can use whatever technique you want to get LESS_TERMCAP_md and LESS_TERMCAP_me set
on the environment before launching `git help git` in whatever way you want.
Now, clearly that technique would vary platform by platform, which is precisely why I'm proposing to do it inside `git help` itself [1].
Clearly this would work on every platform that has less and color and it's technique-independent:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
Would it not?
Less is obviously used across the board (git log, git help, etc.). The assumption of the same starting point for all situations is not valid. For example: my own environment runs git from the following starting points (in order of frequency):
1. Cygwin (bash, yay, easy).
2. OSS (Posix-like, bash, easy).
3. Jenkins (dumb terminal, no colours or else the output gets messed up).
4. GUARDIAN (Not at all Posix-like, I have to supply my own environment variables and the terminal emulator is not vt220 compatible).
5. USS (Posix-like, bash, easy).
6. TSO/ISPF (Not at all Posix-like, I have to supply my own environment variables and the terminal emulator is not vt220 compatible).
In the case of 2-4, this all happens on the same system. Same with 3,5,6. So I have to maintain multiple "less" profiles to maintain output sanity. I cannot do this using .bashrc or .profile because those do not apply. If I had to suffer a single definition set within git, I would lose my mind.
Admittedly, I am in a highly complex situation, but it is a real one (ok, two because of a diverged path between NonStop and MVS) and there are hundreds in a similar situation.
-Randall
From: Felipe Contreras <hidden> Date: 2021-06-28 20:18:04
Randall S. Becker wrote:
On June 28, 2021 3:44 PM, Felipe Contreras wrote:
quoted
Clearly this would work on every platform that has less and color and it's technique-independent:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
Would it not?
Less is obviously used across the board (git log, git help, etc.). The
assumption of the same starting point for all situations is not valid.
I did not assume any starting point. I don't think you are following
what I'm saying.
I do not want to rely on bash, or any shell, or any version of less, or
any function in the user's .profile, or any wrapper in the users's
~/bin.
Junio and Jeff are the ones that think it should be up to the user to
setup colorize tricks in all their environments. Except they are not
specifying what those tricks are. My question "How dow we educate our
users to configure less?" is a rhetorical one, because I already know it
can't be done (although somebody could prove me wrong by showing such
magical configuration).
I'm saying the **opposite**. I'm saying this should be done in
builtin/help.c *not* .profile.
Admittedly, I am in a highly complex situation, but it is a real one
(ok, two because of a diverged path between NonStop and MVS) and there
are hundreds in a similar situation.
From: Randall S. Becker <hidden> Date: 2021-06-28 20:37:28
On June 28, 2021 4:18 PM, Felipe Contreras wrote:
To: Randall S. Becker <redacted>; 'Felipe Contreras' <redacted>; git@vger.kernel.org
Cc: 'Junio C Hamano' <redacted>; git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' <redacted>; 'Jeff King'
[off-list ref]
Subject: RE: How dow we educate our users to configure less?
Randall S. Becker wrote:
quoted
On June 28, 2021 3:44 PM, Felipe Contreras wrote:
quoted
quoted
Clearly this would work on every platform that has less and color and it's technique-independent:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
Would it not?
Less is obviously used across the board (git log, git help, etc.). The
assumption of the same starting point for all situations is not valid.
I did not assume any starting point. I don't think you are following what I'm saying.
I do not want to rely on bash, or any shell, or any version of less, or any function in the user's .profile, or any wrapper in the users's ~/bin.
Junio and Jeff are the ones that think it should be up to the user to setup colorize tricks in all their environments. Except they are not
specifying what those tricks are. My question "How dow we educate our users to configure less?" is a rhetorical one, because I already
know it can't be done (although somebody could prove me wrong by showing such magical configuration).
I'm saying the **opposite**. I'm saying this should be done in builtin/help.c *not* .profile.
quoted
Admittedly, I am in a highly complex situation, but it is a real one
(ok, two because of a diverged path between NonStop and MVS) and there
are hundreds in a similar situation.
My patch [1] should work in all your environments.
Your patch will work in the environments but not in the use case I tried to explain. I do not want a single configuration of less colours in .git/config or ~/.gitconfig. That is not going to work in my situation. I have multiple less colour values that would apply within a given arbitrary timeframe. The configuration depends on the specific terminal type set in the environment, either dumb, vt220, t653x, xterm, cygwin, all of which may happy in short succession. I do not expect it to be practical to change my git settings to conform to this patch, so I am trying to point out that I do not see how it can solve my issue.
The current support, using the TERM environment variable, which is passed to git in all situations either by the system itself on through scripts as is the case with Jenkins, is mostly sufficient for less and git to find its appropriate termcap on all platforms that I use on an ongoing basis (Windows Cygwin, NonStop OSS, NonStop GUARDIAN, Ubuntu, MacOS, MVS, USS, Jenkins). The NonStop GUARDIAN environment does present some paging issues that do not work correctly in some cases with some terminal emulators, but that's the emulator's problem, not the termcap specifically.
So what am I missing?
-Randall
From: Felipe Contreras <hidden> Date: 2021-06-28 20:51:11
Randall S. Becker wrote:
On June 28, 2021 4:18 PM, Felipe Contreras wrote:
quoted
Randall S. Becker wrote:
quoted
I'm saying the **opposite**. I'm saying this should be done in builtin/help.c *not* .profile.
quoted
Admittedly, I am in a highly complex situation, but it is a real one
(ok, two because of a diverged path between NonStop and MVS) and there
are hundreds in a similar situation.
My patch [1] should work in all your environments.
Your patch will work in the environments but not in the use case I
tried to explain. I do not want a single configuration of less colours
in .git/config or ~/.gitconfig. That is not going to work in my
situation. I have multiple less colour values that would apply within
a given arbitrary timeframe. The configuration depends on the specific
terminal type set in the environment, either dumb, vt220, t653x,
xterm, cygwin, all of which may happy in short succession. I do not
expect it to be practical to change my git settings to conform to this
patch, so I am trying to point out that I do not see how it can solve
my issue.
Are you talking about color settings? If so, what are the values of
LESS_TERMCAP_* that you have configured?
The current support, using the TERM environment variable, which is
passed to git in all situations either by the system itself on through
scripts as is the case with Jenkins, is mostly sufficient for less and
git to find its appropriate termcap on all platforms that I use on an
ongoing basis (Windows Cygwin, NonStop OSS, NonStop GUARDIAN, Ubuntu,
MacOS, MVS, USS, Jenkins). The NonStop GUARDIAN environment does
present some paging issues that do not work correctly in some cases
with some terminal emulators, but that's the emulator's problem, not
the termcap specifically.
So what am I missing?
You still have not explained why this would not work on any of your
environments:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
--
Felipe Contreras
From: Randall S. Becker <hidden> Date: 2021-06-28 20:57:08
On June 28, 2021 4:51 PM, Felipe Contreras wrote:
To: Randall S. Becker <redacted>; 'Felipe Contreras' <redacted>; git@vger.kernel.org
Cc: 'Junio C Hamano' <redacted>; git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' <redacted>; 'Jeff King'
[off-list ref]
Subject: RE: How dow we educate our users to configure less?
Randall S. Becker wrote:
quoted
On June 28, 2021 4:18 PM, Felipe Contreras wrote:
quoted
Randall S. Becker wrote:
quoted
quoted
I'm saying the **opposite**. I'm saying this should be done in builtin/help.c *not* .profile.
quoted
Admittedly, I am in a highly complex situation, but it is a real
one (ok, two because of a diverged path between NonStop and MVS)
and there are hundreds in a similar situation.
My patch [1] should work in all your environments.
Your patch will work in the environments but not in the use case I
tried to explain. I do not want a single configuration of less colours
in .git/config or ~/.gitconfig. That is not going to work in my
situation. I have multiple less colour values that would apply within
a given arbitrary timeframe. The configuration depends on the specific
terminal type set in the environment, either dumb, vt220, t653x,
xterm, cygwin, all of which may happy in short succession. I do not
expect it to be practical to change my git settings to conform to this
patch, so I am trying to point out that I do not see how it can solve
my issue.
Are you talking about color settings? If so, what are the values of
LESS_TERMCAP_* that you have configured?
quoted
The current support, using the TERM environment variable, which is
passed to git in all situations either by the system itself on through
scripts as is the case with Jenkins, is mostly sufficient for less and
git to find its appropriate termcap on all platforms that I use on an
ongoing basis (Windows Cygwin, NonStop OSS, NonStop GUARDIAN, Ubuntu,
MacOS, MVS, USS, Jenkins). The NonStop GUARDIAN environment does
present some paging issues that do not work correctly in some cases
with some terminal emulators, but that's the emulator's problem, not
the termcap specifically.
So what am I missing?
You still have not explained why this would not work on any of your
environments:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
I am not saying it will not work technically. Suppose I have a terminal session using t653x, which is not vt220 compatible - meaning it does not use GIT_COLOR_BOLD_RED or even have the concept of bold red) and do a git log or git help. I have another session using vt220, which works as configured. I have a third session running in Jenkins that keeps things up to date and is a terminal type dumb. Your patch appears to imply that I need to run git config to change the values associated with colours to make things work, correct? So how do the three sessions all work simultaneously or do I only get to use one of them at a time and reconfigure when I want to use a different terminal?
From: Felipe Contreras <hidden> Date: 2021-06-28 21:09:09
Randall S. Becker wrote:
On June 28, 2021 4:51 PM, Felipe Contreras wrote:
quoted
To: Randall S. Becker <redacted>; 'Felipe Contreras' <redacted>; git@vger.kernel.org
Cc: 'Junio C Hamano' <redacted>; git@vger.kernel.org; 'Ævar Arnfjörð Bjarmason' <redacted>; 'Jeff King'
[off-list ref]
Subject: RE: How dow we educate our users to configure less?
Randall S. Becker wrote:
quoted
On June 28, 2021 4:18 PM, Felipe Contreras wrote:
quoted
Randall S. Becker wrote:
quoted
quoted
I'm saying the **opposite**. I'm saying this should be done in builtin/help.c *not* .profile.
quoted
Admittedly, I am in a highly complex situation, but it is a real
one (ok, two because of a diverged path between NonStop and MVS)
and there are hundreds in a similar situation.
My patch [1] should work in all your environments.
Your patch will work in the environments but not in the use case I
tried to explain. I do not want a single configuration of less colours
in .git/config or ~/.gitconfig. That is not going to work in my
situation. I have multiple less colour values that would apply within
a given arbitrary timeframe. The configuration depends on the specific
terminal type set in the environment, either dumb, vt220, t653x,
xterm, cygwin, all of which may happy in short succession. I do not
expect it to be practical to change my git settings to conform to this
patch, so I am trying to point out that I do not see how it can solve
my issue.
Are you talking about color settings? If so, what are the values of
LESS_TERMCAP_* that you have configured?
quoted
The current support, using the TERM environment variable, which is
passed to git in all situations either by the system itself on through
scripts as is the case with Jenkins, is mostly sufficient for less and
git to find its appropriate termcap on all platforms that I use on an
ongoing basis (Windows Cygwin, NonStop OSS, NonStop GUARDIAN, Ubuntu,
MacOS, MVS, USS, Jenkins). The NonStop GUARDIAN environment does
present some paging issues that do not work correctly in some cases
with some terminal emulators, but that's the emulator's problem, not
the termcap specifically.
So what am I missing?
You still have not explained why this would not work on any of your
environments:
setenv("LESS_TERMCAP_md", GIT_COLOR_BOLD_RED, 0);
setenv("LESS_TERMCAP_me", GIT_COLOR_RESET, 0);
I am not saying it will not work technically. Suppose I have a
terminal session using t653x, which is not vt220 compatible - meaning
it does not use GIT_COLOR_BOLD_RED or even have the concept of bold
red) and do a git log or git help. I have another session using vt220,
which works as configured. I have a third session running in Jenkins
that keeps things up to date and is a terminal type dumb.
Does `git grep` show colors?
Your patch appears to imply that I need to run git config to change
the values associated with colours to make things work, correct?
No, you just need to enable color.man
git -c color.man=true help git
So how do the three sessions all work simultaneously or do I only get
to use one of them at a time and reconfigure when I want to use a
different terminal?
Do you need to reconfigure anything for `git grep` to show color?
--
Felipe Contreras