git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Phillip Wood" <phillip.wood123@gmail.com>,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Leah Neukirchen" <leah@vuxu.org>,
	"Randall S. Becker" <rsbecker@nexbridge.com>
Subject: Re: [PATCH v4] help: colorize man pages
Date: Fri, 21 May 2021 04:44:22 -0400	[thread overview]
Message-ID: <YKdy5jhHgG2who27@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqbl94smjb.fsf@gitster.g>

On Fri, May 21, 2021 at 02:06:48PM +0900, Junio C Hamano wrote:

> 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.

I still don't understand what we gain by making this a Git feature, as
all of the changed behavior is totally within the program we are
calling. Imagine that konqueror (or an html viewer like firefox) had an
option to set its color scheme from the command line. Should we
introduce a new baked-in fancy-konqueror backend that is "run the tool
with a tweaked color scheme"?

Why would we do that versus saying: if you want to change the colors in
the tool that Git calls, then configure the tool?

If you like to see colors in manpages, why not configure "man" (either
by setting these environment variables all the time, or by triggering
them in MANPAGER)? And then Git doesn't have to care either way; it is
calling "man" which does what the user wants, colors or no. If you
really for some reason only want colorized man pages when called via
"git help", then why not set man.fancy.cmd to invoke your preferred
config?

If those configurations are awkward to trigger via man (e.g., putting
escapes into termcap variables), isn't that something that could be
improved in man? And then it would benefit everyone who uses man, not
just Git.

-Peff

  reply	other threads:[~2021-05-21  8:44 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
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 [this message]
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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YKdy5jhHgG2who27@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leah@vuxu.org \
    --cc=phillip.wood123@gmail.com \
    --cc=rsbecker@nexbridge.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).