git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>, Jeff King <peff@peff.net>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	git@vger.kernel.org,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH] doc: explain the use of color.pager
Date: Wed, 19 May 2021 15:39:37 -0500	[thread overview]
Message-ID: <60a5778992ddd_1b578208e3@natae.notmuch> (raw)
In-Reply-To: <YKVsw3uqb66ifzvd@google.com>

Jonathan Nieder wrote:

> More importantly, I think I'd find a reference to the commit or a
> quotation from the affected user more helpful than a reference to the
> mailing list archive, since that would make this a bit more
> self-contained.

And for me it's the opposite; I find what one user found at one point in
time long ago not particularly important. At best it's a footnote.

> [...]
> > --- a/Documentation/config/color.txt
> > +++ b/Documentation/config/color.txt
> > @@ -127,8 +127,9 @@ color.interactive.<slot>::
> >  	interactive commands.
> >  
> >  color.pager::
> > -	A boolean to enable/disable colored output when the pager is in
> > -	use (default is true).
> > +	A boolean to specify whether `auto` color modes should colorize
> > +	output going to the pager. Defaults to true; set this to false
> > +	if your pager does not understand ANSI color codes.
> 
> I quite like the "set this to false if your pager does not understand
> ANSI color codes" part --- short and to the point.
> 
> The sentence before takes me long enough to understand that I don't
> think we've gotten the wording right yet.  Before I suggest some
> wording, let's make sure I understand the behavior correctly:
> 
> - unlike other color.* settings, this can only be "true" or "false".
>   It cannot be "auto".
> 
> - in other color.* settings, "auto" means "colors are used only when
>   stderr goes to a terminal".  A pager typically ultimately writes to
>   a terminal, but (1) it's not guaranteed to (e.g., xless writes to
>   its own window instead) and (2) more importantly for us, it's not
>   guaranteed to write terminal escapes as is.
> 
> - so this setting can be used to answer "for the sake of evaluating
>   color settings, should we treat output that is going to a pager as
>   going to a terminal?"

Correct.

> If I understood correctly, how about some text like the following?
> 
> 	A boolean to specify whether `auto` color modes should colorize
> 	output going to a pager, in addition to their behavior of
> 	colorizing output going to a terminal.

The "in adittion" part is unnecessary. You don't say "the rest of git's
behavior remains unafffected" on every single configuration. That is
obvious.

We are specifying what happens when output is going to a pager, that's
it.

Everything else--including what happens when the output going to
different programs--it not relevant.

In addition, as far as I can recall there are no commands that send
output both to a pager and to a terminal.

> Side note, not about this patch: we treat pager.color as a synonym for
> color.pager.  Is that something we want to document, or is that an
> instance of being extra friendly when the user makes a typo?

I suspect pager.color is a remnant from an ancient suboptimal name choice.

-- 
Felipe Contreras

  reply	other threads:[~2021-05-19 20:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-19  9:17 [PATCH] doc: explain the use of color.pager Jeff King
2021-05-19 10:41 ` Felipe Contreras
2021-05-19 19:53 ` Jonathan Nieder
2021-05-19 20:39   ` Felipe Contreras [this message]
2021-05-19 22:47   ` Junio C Hamano
2021-05-20  6:36   ` Junio C Hamano
2021-05-20  8:33     ` Jeff King
2021-05-20 15:05       ` Jonathan Nieder

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=60a5778992ddd_1b578208e3@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=peff@peff.net \
    /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).