git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Phillip Wood <phillip.wood123@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	git@vger.kernel.org
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Leah Neukirchen" <leah@vuxu.org>, "Jeff King" <peff@peff.net>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Randall S. Becker" <rsbecker@nexbridge.com>
Subject: Re: [PATCH v4] help: colorize man pages
Date: Thu, 20 May 2021 08:58:41 -0500	[thread overview]
Message-ID: <60a66b11d6ffd_2448320885@natae.notmuch> (raw)
In-Reply-To: <842221d6-51c4-e08a-4299-c4efb8bf1dcb@gmail.com>

Phillip Wood wrote:
> 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

It makes a difference for git developers, not for the user.

The user doesn't care how the output of `git grep` was generated, all
she sees is that it's different from `grep`. It's in fact more
surprising than a difference in `git help` because it's even the same
comand.

Maybe if the command was `git man` they would be equally surprising, but
it's not, in fact, `git help` can be used to 1) output directly to the
terminal 2) view in a browser, 3) view in info program, 4) view man page
in woman, 5) view the man page in koqueror 6) view the man page in man.

Only in one case among many would the user expect to see man, therefore
a colorized `git grep` is more surprising.

> > Our man pages don't contain many useful colors (just blue links),
> > moreover, many people have groff SGR disabled, so they don't see any
> > colors with man pages.
> > 
> > We can set the LESS variable to render bold, underlined, and standout
> > text with colors in the less pager.
> > 
> > Bold is rendered as red, underlined as blue, and standout (prompt and
> > highlighted search) as inverse magenta.
> > 
> > Obviously this only works when the less pager is used.
> > 
> > If the user has already set the LESS variable in his/her environment,
> > that is respected, and nothing changes.
> 
> However if they have specified the colors they would like by using the 
> LESS_TERMCAP_xx environment variables that the previous versions of this 
> patch used their choice is overridden by this new patch.

That is true. We could add a check for that:

  if (getenv("LESS_TERMCAP_md"))
          return;

However, it may not be necessary since many of the tips online set these
variables inside a function.

> I've got LESS_TERMCAP_xx set and running
> 	LESS='Dd+r$Du+b$Ds' man git add
> changes the output colors

You have them set in the environtment? Not inside a function like
man () { ... command man "$@" } ?

> > A new color configuration is added: `color.man` for the people that want
> > to turn this feature off, otherwise `color.ui` is respected.
> > Additionally, if color.pager is not enabled, this is disregarded.
> > 
> > Normally check_auto_color() would check the value of `color.pager`, but
> > in this particular case it's not git the one executing the pager, but
> 
> s/git the one/git is not/

You mean s/it's not git/git is not/

Fine by me.

Cheers.

-- 
Felipe Contreras

  reply	other threads:[~2021-05-20 14:00 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 [this message]
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
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=60a66b11d6ffd_2448320885@natae.notmuch \
    --to=felipe.contreras@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leah@vuxu.org \
    --cc=peff@peff.net \
    --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).