All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Subject: Re: Man pages have colors? A deep dive into groff
Date: Mon, 17 May 2021 23:27:23 -0500	[thread overview]
Message-ID: <60a3422b9556c_14d1bc2082f@natae.notmuch> (raw)
In-Reply-To: <xmqqim3g4ys5.fsf@gitster.g>

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:

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

That is not true. check_auto_color() returns 1 when the fd is a tty.

For example advice() would indirectly call check_auto_color() and no
pager is involved.

Inside the help built-in want_color(GIT_COLOR_UNKNOWN) will always
return 1 (unless you do something like `git help git > file`).

pager_use_color is completely ignored in this case.

It's used only when 1) the fd is not a tty, 2) it's stdout, 3) git is
using a pager... Only _then_ it checks for pager_use_color
(color.pager).

So no; the first purpose of check_auto_color() is to find out if the fd
is capable of showing colors, secondary, if we are using a pager, then
check the user configuration.

In the case we are using a pager it's not check if the pager is capable
of colors, the pager could be capable of colors and yet the user would
disable them: it's the check for the user preference.

> So in short, the color.pager is about "is the pager capable of
> colors?"

That's not the case.

Even the documentation says so:

  color.pager::
    A boolean to enable/disable colored output when the pager is in
    use (default is true).

> and the color.ui (and color.<cmd>) is about "does the user
> wants output from <cmd> in color?"

> Tying it directly to "color.pager" is wrong.

Why? color.pager is to enable/disable colored output when a pager is in
use.

The fact that it's man executing the pager and not git makes no
difference to the user.

Cheers.

-- 
Felipe Contreras

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

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 22:10 Man pages have colors? A deep dive into groff 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
2021-05-18  4:27         ` Felipe Contreras [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=60a3422b9556c_14d1bc2082f@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.