On June 28, 2021 4:18 PM, Felipe Contreras wrote:
>To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx>; 'Felipe Contreras' <felipe.contreras@xxxxxxxxx>; git@xxxxxxxxxxxxxxx
>Cc: 'Junio C Hamano' <gitster@xxxxxxxxx>; git@xxxxxxxxxxxxxxx; 'Ævar Arnfjörð Bjarmason' <avarab@xxxxxxxxx>; 'Jeff King'
><peff@xxxxxxxx>
>Subject: RE: How dow we educate our users to configure less?
>
>Randall S. Becker wrote:
>> On June 28, 2021 3:44 PM, Felipe Contreras wrote:
>
>> >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.
>
>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
