Re: [PATCH v4] help: colorize man pages
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- May 21, 2021, 17:54 UTC
- Message-ID
- <60a7f3d6c55e3_5503920844@natae.notmuch>
- In-Reply-To
- <xmqqbl94smjb.fsf@gitster.g>
Junio C Hamano wrote:
Show 26 quoted lines
> Phillip Wood <phillip.wood123@gmail.com> writes: > > > 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 - 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