From: Phillip Wood <phillip.wood123@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>, git@vger.kernel.org
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Leah Neukirchen" <leah@vuxu.org>, "Jeff King" <peff@peff.net>,
"Junio C Hamano" <gitster@pobox.com>,
"Randall S. Becker" <rsbecker@nexbridge.com>,
"Brian M. Carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH v4] help: colorize man pages
Date: Thu, 20 May 2021 16:13:47 +0100 [thread overview]
Message-ID: <b58cbdcc-abd3-ec82-7d8d-771f47c484ff@gmail.com> (raw)
In-Reply-To: <60a66b11d6ffd_2448320885@natae.notmuch>
On 20/05/2021 14:58, Felipe Contreras wrote:
> Phillip Wood wrote:
>> On 20/05/2021 05:07, Felipe Contreras wrote:
>>> 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
>
> It makes a difference for git developers, not for the user.
>
> The user doesn't care how the output of `git grep` was generated, all
> she sees is that it's different from `grep`. It's in fact more
> surprising than a difference in `git help` because it's even the same
> comand.
>
> Maybe if the command was `git man` they would be equally surprising, but
> it's not, in fact, `git help` can be used to 1) output directly to the
> terminal 2) view in a browser, 3) view in info program, 4) view man page
> in woman, 5) view the man page in koqueror 6) view the man page in man.
>
> Only in one case among many would the user expect to see man, therefore
> a colorized `git grep` is more surprising.
I'm not sure I follow that argument
>>> Our man pages don't contain many useful colors (just blue links),
>>> moreover, many people have groff SGR disabled, so they don't see any
>>> colors with man pages.
>>>
>>> We can set the LESS variable to render bold, underlined, and standout
>>> text with colors in the less pager.
>>>
>>> Bold is rendered as red, underlined as blue, and standout (prompt and
>>> highlighted search) as inverse magenta.
>>>
>>> Obviously this only works when the less pager is used.
>>>
>>> If the user has already set the LESS variable in his/her environment,
>>> that is respected, and nothing changes.
>>
>> However if they have specified the colors they would like by using the
>> LESS_TERMCAP_xx environment variables that the previous versions of this
>> patch used their choice is overridden by this new patch.
>
> That is true. We could add a check for that:
>
> if (getenv("LESS_TERMCAP_md"))
> return;
>
> However, it may not be necessary since many of the tips online set these
> variables inside a function.
The only person who has tested this patch has reported a problem with
it, it seems unlikely that no other users will have similar issues. The
Arch Linux wiki (which I think is probably where I got the idea to set
LESS_TERMCAP_xx) has a section on less[1] suggesting that
LESS_TERMCAP_xx is exported unconditionally in .bashrc, and a later on
man suggesting setting them in a function.
Best Wishes
Phillip
[1]
https://wiki.archlinux.org/title/Color_output_in_console#less
>> I've got LESS_TERMCAP_xx set and running
>> LESS='Dd+r$Du+b$Ds' man git add
>> changes the output colors
>
> You have them set in the environtment? Not inside a function like
> man () { ... command man "$@" } ?
>
>>> A new color configuration is added: `color.man` for the people that want
>>> to turn this feature off, otherwise `color.ui` is respected.
>>> Additionally, if color.pager is not enabled, this is disregarded.
>>>
>>> Normally check_auto_color() would check the value of `color.pager`, but
>>> in this particular case it's not git the one executing the pager, but
>>
>> s/git the one/git is not/
>
> You mean s/it's not git/git is not/
>
> Fine by me.
>
> Cheers.
>
next prev parent reply other threads:[~2021-05-20 15:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-20 4:07 [PATCH v4] help: colorize man pages Felipe Contreras
2021-05-20 9:26 ` Phillip Wood
2021-05-20 13:58 ` Felipe Contreras
2021-05-20 15:13 ` Phillip Wood [this message]
2021-05-20 15:59 ` Felipe Contreras
2021-05-20 18:00 ` Phillip Wood
2021-05-21 17:43 ` Felipe Contreras
2021-05-21 5:06 ` Junio C Hamano
2021-05-21 8:44 ` Jeff King
2021-05-21 18:01 ` Felipe Contreras
2021-05-21 20:26 ` Jeff King
2021-05-21 21:40 ` Felipe Contreras
2021-05-22 9:55 ` Jeff King
2021-05-22 12:43 ` Philip Oakley
2021-05-22 20:53 ` Felipe Contreras
2021-05-22 20:49 ` Felipe Contreras
2021-05-21 17:54 ` Felipe Contreras
2021-05-20 14:39 ` Leah Neukirchen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b58cbdcc-abd3-ec82-7d8d-771f47c484ff@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=avarab@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=leah@vuxu.org \
--cc=peff@peff.net \
--cc=phillip.wood@dunelm.org.uk \
--cc=rsbecker@nexbridge.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).