Re: [PATCH] help: colorize man pages

"brian m. carlson" [off-list ref] writes:

The documentation says, "use the man program as usual".  "As usual"
implies the way the user would invoke it.

I guess what the documentation says matches what end users expect (I
as an end user certainly do expect that "git help -m foo" is running
the familiar "man" command on something that is related to "foo").

So while making the "less" customization more discoverable and
easily accessible would be a win for users, I have to agree that is
out of scope of this project's mission.

We used to give helpful hints how to configure LESS environment
variable in a way that does not conflict with our use somewhere in
the doc.  I think the hints how to configure these set of environment
variables for "less" users may belong to a similar place in the doc,
if we wanted to do something, but going beyond that would probably
be more confusing and disorienting than helpful to our users (they'll
start wondering why "git help"'s output does not look like the
output from "man ls").

Thanks for discussing this topic.

Junio C Hamano wrote:

"brian m. carlson" [off-list ref] writes:

quoted

The documentation says, "use the man program as usual".  "As usual"
implies the way the user would invoke it.

I guess what the documentation says matches what end users expect (I
as an end user certainly do expect that "git help -m foo" is running
the familiar "man" command on something that is related to "foo").

Do you also expect that `git diff a b` runs something similar to
`diff a b`?

So while making the "less" customization more discoverable and
easily accessible would be a win for users, I have to agree that is
out of scope of this project's mission.

How is enabling a configuration already present in `man` out of scope,
but running an *ENTIRELY* different program--such as konqueror or
woman--to view man pages is not?

  git help --man git

Doesn't even necessarily run man *already*.

-- 
Felipe Contreras