list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Felipe Contreras <>
Cc: "Ævar Arnfjörð Bjarmason" <>,
Subject: Re: Man pages have colors? A deep dive into groff
Date: Tue, 18 May 2021 10:27:06 +0900	[thread overview]
Message-ID: <xmqqim3g4ys5.fsf@gitster.g> (raw)
In-Reply-To: <60a2f1c4cab0d_13c3702083a@natae.notmuch> (Felipe Contreras's message of "Mon, 17 May 2021 17:44:20 -0500")

Felipe Contreras <> writes:

> Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason <> writes:
>> > This looks much better.
>> >
>> > I wonder a good follow-up (hint, hint! :) would be to have
>> > exec_man_man() and exec_man_cmd() in builtin/help.c set this depending
>> > on color.ui (so we'd do it by default with "auto").
>> >
>> > Then e.g. "git help git" would look prettier than "man git".
>> As long as can be used to override the blanket
>> color.ui, I think it is a good idea.
> Why not use color.pager?

I dug a bit to refresh my memory and it turns out that the reason we
should not do so is because it means something totally different.

color.[ch] defines want_color() that applications like "diff" and
"log" can use to see if the application is configured to paint its
output in colors.

When that layer says for that particular application it should be
decided automatically, then we call into color.c::check_auto_color()
which is the only user of pager_use_color (which is set from the
color.pager configuration variable).  The purpose of that call is to
ask if the pager is capable of colors.

So in short, the color.pager is about "is the pager capable of
colors?"  and the color.ui (and color.<cmd>) is about "does the user
wants output from <cmd> in color?"  We need to use or
something that controls whether the user wants help/man in colors,
and perhaps default it to "auto" like color.ui defaults to, which
then in turn would consult "color.pager".  Tying it directly to
"color.pager" is wrong.

  parent reply	other threads:[~2021-05-18  1:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 22:10 Felipe Contreras
2021-05-17 16:48 ` Ævar Arnfjörð Bjarmason
2021-05-17 19:28   ` Junio C Hamano
2021-05-17 22:44     ` Felipe Contreras
2021-05-17 22:54       ` Randall S. Becker
2021-05-17 23:33         ` Felipe Contreras
2021-05-18  1:27       ` Junio C Hamano [this message]
2021-05-18  4:27         ` Felipe Contreras
2021-05-18  7:16           ` Jeff King
2021-05-18 13:21             ` Felipe Contreras
2021-05-18 14:27             ` Junio C Hamano
2021-05-18  1:28   ` brian m. carlson
2021-05-18  2:12     ` Junio C Hamano
2021-05-18  4:35       ` Felipe Contreras
2021-05-18  4:31     ` Felipe Contreras

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:

  List information:

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

  git send-email \
    --in-reply-to=xmqqim3g4ys5.fsf@gitster.g \ \ \ \ \

* 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 inbox:

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