Re: [PATCH v4] help: colorize man pages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano wrote:
> Phillip Wood <phillip.wood123@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux