git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
To: "Felipe Contreras" <felipe.contreras@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, "Randall S. Becker" <rsbecker@nexbridge.com>,
	Leah Neukirchen <leah@vuxu.org>
Subject: Re: [PATCH] help: colorize man pages
Date: Sat, 22 May 2021 00:10:38 +0200	[thread overview]
Message-ID: <636007b7-c079-f8a6-1b26-eb2a55505354@gmail.com> (raw)
In-Reply-To: <60a8243323625_77e4f208f8@natae.notmuch>

On 21/05/2021 23:20, Felipe Contreras wrote:
> Igor Djordjevic wrote:
> > 
> > If I may, NO_COLOR approach seems to be rather straightforward to me, 
> > as per description on their homepage[1] - make all software supporting 
> > it behave as colors are an opt-in feature, thus disabled by default.
> 
> May I ask you how you interpret this?
> 
>   It is reasonable to configure certain software such as a text editor
>   to use color ... sparingly

Sure, but to make the point (hopefully) even more obvious, let me 
quote the whole part:

  It is reasonable to configure certain software such as a text editor 
  to use color or other ANSI attributes sparingly (such as the reverse 
  attribute for a status bar) while still desiring that other software 
  not add color unless configured to. It should be up to the user 
  whether color is used, not the software author.

I understand it exactly as (I think) it says - it is reasonable to 
allow (the user, not developer!) to configure certain software to 
(still) use color (fully or sparingly should not even matter, and it 
may depend on what kind of granular configuration software allows in 
the first place, if any), even if his (user's) general ("default") 
preference is to have no colors.

Thus color should be user opt-in - NO_COLOR turns all of it off by 
default (for all software supporting it), and user decides which color 
to turn back on through each specific software color configuration.

That last sentence should make it clear - "it should be up to the 
user whether color is used, not the software author".

So it shouldn't matter what does software author think about which 
parts of software should be (fully or sparingly) colored (by default) 
- NO_COLOR's idea is to give the ultimate power to the user to 
decide, and on a global level, starting with no colors by default, 
then allowing colors where desired, per each specific software config 
(instead of vice-versa, being required to turn color off per each 
specific software, where color is otherwise used by default).

At least that's how I understand all of it, making sense to me, but I 
don't mind discussing it further, if needed.

  reply	other threads:[~2021-05-21 22:10 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18  1:01 Felipe Contreras
2021-05-18  1:19 ` brian m. carlson
2021-05-18  3:22   ` Felipe Contreras
2021-05-18 23:49     ` brian m. carlson
2021-05-19  1:08       ` Junio C Hamano
2021-05-19  2:07         ` brian m. carlson
2021-05-19  6:09           ` Junio C Hamano
2021-05-19  8:41             ` Ævar Arnfjörð Bjarmason
2021-05-19 10:36               ` Felipe Contreras
2021-05-21  0:58               ` brian m. carlson
2021-05-21 18:09                 ` Felipe Contreras
2021-05-21 19:48                   ` Igor Djordjevic
2021-05-21 21:20                     ` Felipe Contreras
2021-05-21 22:10                       ` Igor Djordjevic [this message]
2021-05-21 23:04                         ` Felipe Contreras
2021-05-22 18:38                           ` Igor Djordjevic
2021-05-22 21:48                             ` Felipe Contreras
2021-05-23 11:25                               ` Igor Djordjevic
2021-05-23 14:48                                 ` Felipe Contreras
2021-05-21 22:47                     ` Igor Djordjevic
2021-05-21 23:32                     ` Junio C Hamano
2021-05-19  9:26       ` Ævar Arnfjörð Bjarmason
2021-05-19 10:10         ` Jeff King
2021-05-19 11:45           ` Felipe Contreras
2021-05-19 11:19         ` Felipe Contreras
2021-05-19 12:21           ` Felipe Contreras
2021-05-20  1:55         ` brian m. carlson
2021-05-20  2:23           ` Junio C Hamano
2021-05-20  3:05             ` Felipe Contreras
2021-05-20  3:28               ` Junio C Hamano
2021-05-20  3:48                 ` Felipe Contreras
2021-05-20  2:45           ` Felipe Contreras
2021-05-19 10:25       ` 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=636007b7-c079-f8a6-1b26-eb2a55505354@gmail.com \
    --to=igor.d.djordjevic@gmail.com \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=leah@vuxu.org \
    --cc=rsbecker@nexbridge.com \
    --cc=sandals@crustytoothpaste.net \
    --subject='Re: [PATCH] help: colorize man pages' \
    /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

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 NNTP newsgroup(s).