Patchwork color: add default colors for draft and secret changes

login
register
mail settings
Submitter Matt Mackall
Date May 26, 2015, 8:07 p.m.
Message ID <8e4a41b04eb9373da8c3.1432670875@ruin.waste.org>
Download mbox | patch
Permalink /patch/9283/
State Accepted
Headers show

Comments

Matt Mackall - May 26, 2015, 8:07 p.m.
# HG changeset patch
# User Matt Mackall <mpm@selenic.com>
# Date 1432333213 18000
#      Fri May 22 17:20:13 2015 -0500
# Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
# Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
color: add default colors for draft and secret changes

This highlights the changeset number in logs and summary. Together
with log -G, it gives a visual indication of which portions of your
repo are in which phase.

I've chosen draft = magenta and secret = red. Public changesets
currently automatically use yellow today. There are basically no
"good" color choices available in this palette (I have to squint at
most of them), so I'm not going to belabor the selection process.
Pierre-Yves David - May 26, 2015, 8:37 p.m.
On 05/26/2015 01:07 PM, Matt Mackall wrote:
> # HG changeset patch
> # User Matt Mackall <mpm@selenic.com>
> # Date 1432333213 18000
> #      Fri May 22 17:20:13 2015 -0500
> # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
> # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
> color: add default colors for draft and secret changes
>
> This highlights the changeset number in logs and summary. Together
> with log -G, it gives a visual indication of which portions of your
> repo are in which phase.
>
> I've chosen draft = magenta and secret = red. Public changesets
> currently automatically use yellow today. There are basically no
> "good" color choices available in this palette (I have to squint at
> most of them), so I'm not going to belabor the selection process.
>
> diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
> --- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
> +++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
> @@ -78,8 +78,8 @@
>
>     # Blank so it inherits the style of the surrounding label
>     changeset.public =
> -  changeset.draft =
> -  changeset.secret =
> +  changeset.draft = magenta
> +  changeset.secret = red

I think we should keep 'red' for stronger message.

1) I've been using 'red' for 'troubled' changeset at Facebook with 
significant success (and grey for obsolete one)

2) I've some experiment laying around to have all stderr output 'yellow' 
and actual error message (like abort) 'red'

What about:

public: yellow
draft:  magenta
secret: cyan or blue

(blue is often miss rendered as to dark by mac)
Jordi Gutiérrez Hermoso - May 26, 2015, 8:44 p.m.
On Tue, 2015-05-26 at 13:37 -0700, Pierre-Yves David wrote:
> 
> On 05/26/2015 01:07 PM, Matt Mackall wrote:
> > # HG changeset patch
> > # User Matt Mackall <mpm@selenic.com>
> > # Date 1432333213 18000
> > #      Fri May 22 17:20:13 2015 -0500
> > # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
> > # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
> > color: add default colors for draft and secret changes

Nice! I've been wanting this by default for a while.

> > I've chosen draft = magenta and secret = red. Public changesets
> > currently automatically use yellow today. There are basically no
> > "good" color choices available in this palette (I have to squint at
> > most of them), so I'm not going to belabor the selection process.
[snip]
> I think we should keep 'red' for stronger message.
[snip]
> public: yellow
> draft:  magenta
> secret: cyan or blue

Yeah, I use blue for the secret phase. It looks subdued and sneaky.
Kyle Lippincott - May 26, 2015, 9:04 p.m.
On Tue, May 26, 2015 at 1:37 PM, Pierre-Yves David <
pierre-yves.david@ens-lyon.org> wrote:

>
>
> On 05/26/2015 01:07 PM, Matt Mackall wrote:
>
>> # HG changeset patch
>> # User Matt Mackall <mpm@selenic.com>
>> # Date 1432333213 18000
>> #      Fri May 22 17:20:13 2015 -0500
>> # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
>> # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
>> color: add default colors for draft and secret changes
>>
>> This highlights the changeset number in logs and summary. Together
>> with log -G, it gives a visual indication of which portions of your
>> repo are in which phase.
>>
>> I've chosen draft = magenta and secret = red. Public changesets
>> currently automatically use yellow today. There are basically no
>> "good" color choices available in this palette (I have to squint at
>> most of them), so I'm not going to belabor the selection process.
>>
>> diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
>> --- a/hgext/color.py    Fri May 22 17:08:59 2015 -0500
>> +++ b/hgext/color.py    Fri May 22 17:20:13 2015 -0500
>> @@ -78,8 +78,8 @@
>>
>>     # Blank so it inherits the style of the surrounding label
>>     changeset.public =
>> -  changeset.draft =
>> -  changeset.secret =
>> +  changeset.draft = magenta
>> +  changeset.secret = red
>>
>
> I think we should keep 'red' for stronger message.
>
> 1) I've been using 'red' for 'troubled' changeset at Facebook with
> significant success (and grey for obsolete one)
>
> 2) I've some experiment laying around to have all stderr output 'yellow'
> and actual error message (like abort) 'red'
>
> What about:
>
> public: yellow
>

Not everyone uses a black background (I don't understand why not, but..);
yellow is essentially unreadable on white background. The standard blue is
too dark on black backgrounds, the standard yellow is too light on white
backgrounds.  The 'safe' colors in the 16 normally representable that I've
encountered are:

bright black
red and bright red
green and bright green
dark yellow (aka brown)
magenta and bright magenta
cyan and bright cyan


> draft:  magenta
> secret: cyan or blue
>
> (blue is often miss rendered as to dark by mac)
>
>
>
>
> --
> Pierre-Yves David
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
>
Jordi Gutiérrez Hermoso - May 26, 2015, 9:10 p.m.
On Tue, 2015-05-26 at 14:04 -0700, Kyle Lippincott wrote:
> Not everyone uses a black background (I don't understand why not,
> but..); yellow is essentially unreadable on white background. The
> standard blue is too dark on black backgrounds, the standard yellow
> is too light on white backgrounds. The 'safe' colors in the 16
> normally representable that I've encountered are:

This is a "theme" problem. All ANSI colours are meant to be readable.
Whether the "yellow" ANSI code is dark or light depends on the
terminal emulator. We must assume that all 8 ANSI colours have enough
contrast. It's really only with the 256 extended colours that contrast
has to be taken into consideration.
Matt Mackall - May 26, 2015, 9:24 p.m.
On Tue, 2015-05-26 at 13:37 -0700, Pierre-Yves David wrote:
> 
> On 05/26/2015 01:07 PM, Matt Mackall wrote:
> > # HG changeset patch
> > # User Matt Mackall <mpm@selenic.com>
> > # Date 1432333213 18000
> > #      Fri May 22 17:20:13 2015 -0500
> > # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
> > # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
> > color: add default colors for draft and secret changes
> >
> > This highlights the changeset number in logs and summary. Together
> > with log -G, it gives a visual indication of which portions of your
> > repo are in which phase.
> >
> > I've chosen draft = magenta and secret = red. Public changesets
> > currently automatically use yellow today. There are basically no
> > "good" color choices available in this palette (I have to squint at
> > most of them), so I'm not going to belabor the selection process.
> >
> > diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
> > --- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
> > +++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
> > @@ -78,8 +78,8 @@
> >
> >     # Blank so it inherits the style of the surrounding label
> >     changeset.public =
> > -  changeset.draft =
> > -  changeset.secret =
> > +  changeset.draft = magenta
> > +  changeset.secret = red
> 
> I think we should keep 'red' for stronger message.
> 
> 1) I've been using 'red' for 'troubled' changeset at Facebook with 
> significant success (and grey for obsolete one)

Well... you shoulda sent a patch for that if you wanted to reserve it.
As far as I can tell, there's currently no support for anything
color/label-related in evolve. But maybe you're talking about hgview.

> 2) I've some experiment laying around to have all stderr output 'yellow' 
> and actual error message (like abort) 'red'
> 
> What about:
> 
> public: yellow
> draft:  magenta
> secret: cyan or blue

The most common forms of color vision deficiency (8% of men) are about
weakness or absence of red receptors. Baseline human brightness
sensitivity works something like this (with gamma factored in):

 brightness = red * .1 + blue * .2 + green *.7

In my case, it's more like red * .03: I can see it, it just is not
nearly as intense as other colors. So I can't easily distinguish any
3-bit color pair that is different just in the red bit... except
black/red. So that means in the basic 8-color palette:

rgb
x00 red/black   <- ok relative contrast
x01 blue/magenta <- bad
x10 green/yellow <- worse
x11 cyan/white  <- worst

Given yellow is already chosen and white and black are terminal default
fg/bg colors, that basically leaves me with red and blue/magenta if I
want to use colors (as opposed to attributes) for phases. So I'd accept
one of the following choices:

yellow/magenta/red  yellow/red/magenta
yellow/blue/red     yellow/red/blue

As for changeset obsolescence states, there's a pretty good argument to
make that they should be orthogonal to colors (ie attributes),
especially as you can have obsolete secrets and troubled drafts. Dim for
obsolete and underline for troubled seem good. I'm currently using
inverse for checked out.
Pierre-Yves David - May 26, 2015, 9:35 p.m.
On 05/26/2015 02:24 PM, Matt Mackall wrote:
> On Tue, 2015-05-26 at 13:37 -0700, Pierre-Yves David wrote:
>>
>> On 05/26/2015 01:07 PM, Matt Mackall wrote:
>>> # HG changeset patch
>>> # User Matt Mackall <mpm@selenic.com>
>>> # Date 1432333213 18000
>>> #      Fri May 22 17:20:13 2015 -0500
>>> # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
>>> # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
>>> color: add default colors for draft and secret changes
>>>
>>> This highlights the changeset number in logs and summary. Together
>>> with log -G, it gives a visual indication of which portions of your
>>> repo are in which phase.
>>>
>>> I've chosen draft = magenta and secret = red. Public changesets
>>> currently automatically use yellow today. There are basically no
>>> "good" color choices available in this palette (I have to squint at
>>> most of them), so I'm not going to belabor the selection process.
>>>
>>> diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
>>> --- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
>>> +++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
>>> @@ -78,8 +78,8 @@
>>>
>>>      # Blank so it inherits the style of the surrounding label
>>>      changeset.public =
>>> -  changeset.draft =
>>> -  changeset.secret =
>>> +  changeset.draft = magenta
>>> +  changeset.secret = red
>>
>> I think we should keep 'red' for stronger message.
>>
>> 1) I've been using 'red' for 'troubled' changeset at Facebook with
>> significant success (and grey for obsolete one)
>
> Well... you shoulda sent a patch for that if you wanted to reserve it.
> As far as I can tell, there's currently no support for anything
> color/label-related in evolve. But maybe you're talking about hgview.

This is actually in `hg sl`. I can sure send a patch to move some of 
that into core.

>> 2) I've some experiment laying around to have all stderr output 'yellow'
>> and actual error message (like abort) 'red'
>>
>> What about:
>>
>> public: yellow
>> draft:  magenta
>> secret: cyan or blue
>
> The most common forms of color vision deficiency (8% of men) are about
> weakness or absence of red receptors. Baseline human brightness
> sensitivity works something like this (with gamma factored in):
>
>   brightness = red * .1 + blue * .2 + green *.7
>
> In my case, it's more like red * .03: I can see it, it just is not
> nearly as intense as other colors. So I can't easily distinguish any
> 3-bit color pair that is different just in the red bit... except
> black/red. So that means in the basic 8-color palette:
>
> rgb
> x00 red/black   <- ok relative contrast
> x01 blue/magenta <- bad
> x10 green/yellow <- worse
> x11 cyan/white  <- worst
>
> Given yellow is already chosen and white and black are terminal default
> fg/bg colors, that basically leaves me with red and blue/magenta if I
> want to use colors (as opposed to attributes) for phases. So I'd accept
> one of the following choices:
>
> yellow/magenta/red  yellow/red/magenta
> yellow/blue/red     yellow/red/blue
>
> As for changeset obsolescence states, there's a pretty good argument to
> make that they should be orthogonal to colors (ie attributes),
> especially as you can have obsolete secrets and troubled drafts. Dim for
> obsolete and underline for troubled seem good. I'm currently using
> inverse for checked out.

Were it is used, 'red' is not used to color the node id, it is used to 
color the '{troubles}' content. We probably need a 'troubles' line in hg 
log with such label.

But my point goes further that 'is this data orthogonal'. What I'm 
trying to say here is:

   I would like to revert all 'read' output to 'problematic state' that 
requires user attention.

Putting red to something as casual as 'secret' would jeopardize that.
Kyle Lippincott - May 26, 2015, 9:51 p.m.
On Tue, May 26, 2015 at 2:10 PM, Jordi Gutiérrez Hermoso <jordigh@octave.org
> wrote:

> On Tue, 2015-05-26 at 14:04 -0700, Kyle Lippincott wrote:
> > Not everyone uses a black background (I don't understand why not,
> > but..); yellow is essentially unreadable on white background. The
> > standard blue is too dark on black backgrounds, the standard yellow
> > is too light on white backgrounds. The 'safe' colors in the 16
> > normally representable that I've encountered are:
>
> This is a "theme" problem. All ANSI colours are meant to be readable.
> Whether the "yellow" ANSI code is dark or light depends on the
> terminal emulator. We must assume that all 8 ANSI colours have enough
> contrast. It's really only with the 256 extended colours that contrast
> has to be taken into consideration.
>
>
>
AFAICT ANSI has never stated what the individual color values need to be.
The defaults for cmd.exe, Terminal.app, PuTTY and xterm can be seen at
Wikipedia[0], but of those 4, only Terminal.app has 'bright yellow' be
darker than 255,255,0.  So, we need to worry about it. :(

[0]: http://en.wikipedia.org/wiki/ANSI_escape_code#Colors
Matt Mackall - May 26, 2015, 10:17 p.m.
On Tue, 2015-05-26 at 14:35 -0700, Pierre-Yves David wrote:
> 
> On 05/26/2015 02:24 PM, Matt Mackall wrote:
> > On Tue, 2015-05-26 at 13:37 -0700, Pierre-Yves David wrote:
> >>
> >> On 05/26/2015 01:07 PM, Matt Mackall wrote:
> >>> # HG changeset patch
> >>> # User Matt Mackall <mpm@selenic.com>
> >>> # Date 1432333213 18000
> >>> #      Fri May 22 17:20:13 2015 -0500
> >>> # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
> >>> # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
> >>> color: add default colors for draft and secret changes
> >>>
> >>> This highlights the changeset number in logs and summary. Together
> >>> with log -G, it gives a visual indication of which portions of your
> >>> repo are in which phase.
> >>>
> >>> I've chosen draft = magenta and secret = red. Public changesets
> >>> currently automatically use yellow today. There are basically no
> >>> "good" color choices available in this palette (I have to squint at
> >>> most of them), so I'm not going to belabor the selection process.
> >>>
> >>> diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
> >>> --- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
> >>> +++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
> >>> @@ -78,8 +78,8 @@
> >>>
> >>>      # Blank so it inherits the style of the surrounding label
> >>>      changeset.public =
> >>> -  changeset.draft =
> >>> -  changeset.secret =
> >>> +  changeset.draft = magenta
> >>> +  changeset.secret = red
> >>
> >> I think we should keep 'red' for stronger message.
> >>
> >> 1) I've been using 'red' for 'troubled' changeset at Facebook with
> >> significant success (and grey for obsolete one)
> >
> > Well... you shoulda sent a patch for that if you wanted to reserve it.
> > As far as I can tell, there's currently no support for anything
> > color/label-related in evolve. But maybe you're talking about hgview.
> 
> This is actually in `hg sl`. I can sure send a patch to move some of 
> that into core.
> 
> >> 2) I've some experiment laying around to have all stderr output 'yellow'
> >> and actual error message (like abort) 'red'
> >>
> >> What about:
> >>
> >> public: yellow
> >> draft:  magenta
> >> secret: cyan or blue
> >
> > The most common forms of color vision deficiency (8% of men) are about
> > weakness or absence of red receptors. Baseline human brightness
> > sensitivity works something like this (with gamma factored in):
> >
> >   brightness = red * .1 + blue * .2 + green *.7
> >
> > In my case, it's more like red * .03: I can see it, it just is not
> > nearly as intense as other colors. So I can't easily distinguish any
> > 3-bit color pair that is different just in the red bit... except
> > black/red. So that means in the basic 8-color palette:
> >
> > rgb
> > x00 red/black   <- ok relative contrast
> > x01 blue/magenta <- bad
> > x10 green/yellow <- worse
> > x11 cyan/white  <- worst
> >
> > Given yellow is already chosen and white and black are terminal default
> > fg/bg colors, that basically leaves me with red and blue/magenta if I
> > want to use colors (as opposed to attributes) for phases. So I'd accept
> > one of the following choices:
> >
> > yellow/magenta/red  yellow/red/magenta
> > yellow/blue/red     yellow/red/blue
> >
> > As for changeset obsolescence states, there's a pretty good argument to
> > make that they should be orthogonal to colors (ie attributes),
> > especially as you can have obsolete secrets and troubled drafts. Dim for
> > obsolete and underline for troubled seem good. I'm currently using
> > inverse for checked out.
> 
> Were it is used, 'red' is not used to color the node id, it is used to 
> color the '{troubles}' content. We probably need a 'troubles' line in hg 
> log with such label.
> 
> But my point goes further that 'is this data orthogonal'. What I'm 
> trying to say here is:
> 
>    I would like to revert all 'read' output to 'problematic state' that 
> requires user attention.

That's a great idea.. for people who can see red well. But it's also the
color that I (and many other people) are LEAST likely to notice, so
you're not exactly selling me on this point.

Can I interest you in red_background? This I might notice.
Matt Mackall - May 26, 2015, 10:23 p.m.
On Tue, 2015-05-26 at 14:51 -0700, Kyle Lippincott wrote:
> On Tue, May 26, 2015 at 2:10 PM, Jordi Gutiérrez Hermoso <jordigh@octave.org
> > wrote:
> 
> > On Tue, 2015-05-26 at 14:04 -0700, Kyle Lippincott wrote:
> > > Not everyone uses a black background (I don't understand why not,
> > > but..); yellow is essentially unreadable on white background. The
> > > standard blue is too dark on black backgrounds, the standard yellow
> > > is too light on white backgrounds. The 'safe' colors in the 16
> > > normally representable that I've encountered are:
> >
> > This is a "theme" problem. All ANSI colours are meant to be readable.
> > Whether the "yellow" ANSI code is dark or light depends on the
> > terminal emulator. We must assume that all 8 ANSI colours have enough
> > contrast. It's really only with the 256 extended colours that contrast
> > has to be taken into consideration.
> >
> >
> >
> AFAICT ANSI has never stated what the individual color values need to be.

Nope.. because it was implicit in the design of the dirt-simple displays
that the scheme was created for: direct-driven 3- or 4-bit RGB systems
based on something like a Moto 6845 CRT controller like CGA. Between the
constraints of white balance and uncalibrated CRT gamma curves, the
colors were more or less defined. Historically, the only variables were
"how bright is the intensity bit (if present)" and "is it additive or
multiplicative". Everything in the wikipedia chart assumes palette
registers and DACs.. which postdates ANSI color by about a decade.
Augie Fackler - May 27, 2015, 5:06 a.m.
On Tue, May 26, 2015 at 05:17:34PM -0500, Matt Mackall wrote:
> On Tue, 2015-05-26 at 14:35 -0700, Pierre-Yves David wrote:
> > Were it is used, 'red' is not used to color the node id, it is used to
> > color the '{troubles}' content. We probably need a 'troubles' line in hg
> > log with such label.
> >
> > But my point goes further that 'is this data orthogonal'. What I'm
> > trying to say here is:
> >
> >    I would like to revert all 'read' output to 'problematic state' that
> > requires user attention.
>
> That's a great idea.. for people who can see red well. But it's also the
> color that I (and many other people) are LEAST likely to notice, so
> you're not exactly selling me on this point.
>
> Can I interest you in red_background? This I might notice.

+1 to not trying to make red semantically valuable on the command line
in terms of danger - it's just not easy to read for my eyes in general
(I believe I've tweaked my terminal emulator configs at least on OS X
to be more readable somehow as long as 10 years ago, because red is so
hard to see. It likes to pretend to be black.)

>
> --
> Mathematics is the supreme nostalgia of our time.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@selenic.com
> https://selenic.com/mailman/listinfo/mercurial-devel
Jordi Gutiérrez Hermoso - May 27, 2015, 1:06 p.m.
On Tue, 2015-05-26 at 14:51 -0700, Kyle Lippincott wrote:
> AFAICT ANSI has never stated what the individual color values need
> to be. The defaults for cmd.exe, Terminal.app, PuTTY and xterm can
> be seen at Wikipedia[0], but of those 4, only Terminal.app has
> 'bright yellow' be darker than 255,255,0. So, we need to worry about
> it. :(

I meant the eight base colours without brightness are safe. Those are
the only ones under consideration, I thought.

- Jordi G. H.
Pierre-Yves David - June 1, 2015, 7:11 a.m.
On 05/26/2015 03:17 PM, Matt Mackall wrote:
> On Tue, 2015-05-26 at 14:35 -0700, Pierre-Yves David wrote:
>>
>> On 05/26/2015 02:24 PM, Matt Mackall wrote:
>>> On Tue, 2015-05-26 at 13:37 -0700, Pierre-Yves David wrote:
>>>>
>>>> On 05/26/2015 01:07 PM, Matt Mackall wrote:
>>>>> # HG changeset patch
>>>>> # User Matt Mackall <mpm@selenic.com>
>>>>> # Date 1432333213 18000
>>>>> #      Fri May 22 17:20:13 2015 -0500
>>>>> # Node ID 8e4a41b04eb9373da8c3639edfb060187465809c
>>>>> # Parent  da0105aee52a058e03db3e9c9a187962efc0c7db
>>>>> color: add default colors for draft and secret changes
>>>>>
>>>>> This highlights the changeset number in logs and summary. Together
>>>>> with log -G, it gives a visual indication of which portions of your
>>>>> repo are in which phase.
>>>>>
>>>>> I've chosen draft = magenta and secret = red. Public changesets
>>>>> currently automatically use yellow today. There are basically no
>>>>> "good" color choices available in this palette (I have to squint at
>>>>> most of them), so I'm not going to belabor the selection process.
>>>>>
>>>>> diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
>>>>> --- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
>>>>> +++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
>>>>> @@ -78,8 +78,8 @@
>>>>>
>>>>>       # Blank so it inherits the style of the surrounding label
>>>>>       changeset.public =
>>>>> -  changeset.draft =
>>>>> -  changeset.secret =
>>>>> +  changeset.draft = magenta
>>>>> +  changeset.secret = red
>>>>
>>>> I think we should keep 'red' for stronger message.
>>>>
>>>> 1) I've been using 'red' for 'troubled' changeset at Facebook with
>>>> significant success (and grey for obsolete one)
>>>
>>> Well... you shoulda sent a patch for that if you wanted to reserve it.
>>> As far as I can tell, there's currently no support for anything
>>> color/label-related in evolve. But maybe you're talking about hgview.
>>
>> This is actually in `hg sl`. I can sure send a patch to move some of
>> that into core.
>>
>>>> 2) I've some experiment laying around to have all stderr output 'yellow'
>>>> and actual error message (like abort) 'red'
>>>>
>>>> What about:
>>>>
>>>> public: yellow
>>>> draft:  magenta
>>>> secret: cyan or blue
>>>
>>> The most common forms of color vision deficiency (8% of men) are about
>>> weakness or absence of red receptors. Baseline human brightness
>>> sensitivity works something like this (with gamma factored in):
>>>
>>>    brightness = red * .1 + blue * .2 + green *.7
>>>
>>> In my case, it's more like red * .03: I can see it, it just is not
>>> nearly as intense as other colors. So I can't easily distinguish any
>>> 3-bit color pair that is different just in the red bit... except
>>> black/red. So that means in the basic 8-color palette:
>>>
>>> rgb
>>> x00 red/black   <- ok relative contrast
>>> x01 blue/magenta <- bad
>>> x10 green/yellow <- worse
>>> x11 cyan/white  <- worst
>>>
>>> Given yellow is already chosen and white and black are terminal default
>>> fg/bg colors, that basically leaves me with red and blue/magenta if I
>>> want to use colors (as opposed to attributes) for phases. So I'd accept
>>> one of the following choices:
>>>
>>> yellow/magenta/red  yellow/red/magenta
>>> yellow/blue/red     yellow/red/blue
>>>
>>> As for changeset obsolescence states, there's a pretty good argument to
>>> make that they should be orthogonal to colors (ie attributes),
>>> especially as you can have obsolete secrets and troubled drafts. Dim for
>>> obsolete and underline for troubled seem good. I'm currently using
>>> inverse for checked out.
>>
>> Were it is used, 'red' is not used to color the node id, it is used to
>> color the '{troubles}' content. We probably need a 'troubles' line in hg
>> log with such label.
>>
>> But my point goes further that 'is this data orthogonal'. What I'm
>> trying to say here is:
>>
>>     I would like to revert all 'read' output to 'problematic state' that
>> requires user attention.


Lets try to make this topic move forward.

It is probably time to had "color scheme" information on the wiki:

- What we already have and how it was picked,
- current thing we would like colored,
- What are the constraint on our color (<- This is where mutant related 
data fit)

 From there we can start looking at which color we could reserve for 
"problematic" state.

I think we are supported to have a name scheme (at least for config 
option) page already, but I cannot find it.

> That's a great idea.. for people who can see red well. But it's also the
> color that I (and many other people) are LEAST likely to notice, so
> you're not exactly selling me on this point.

The number of color is limited, and there is also some already 
universal-ish color schemes. For example both clang and gcc use 'red' 
for error.

I'm sympathetic to not making the life of 8% male hard. I'm also 
sympathetic to having more colors and meaningful ones. America have 5% 
of people as badly short-sighted as I am (where eyes correction + screen 
reading are never friends), Europe is worth and Asia is incredibly bad 
in this regard. In the same direction, about a third of the global 
population have some astigmatism, making reading more tiresome. Proper 
color scheme relieve some need for read scrutiny and reduce tiresomeness 
of working on a screen (You have probably noticed the gigantic font and 
the Christmas tree color scheme I use).

The number of basic colors available in a terminal are already extremely 
low, dropping one bit would make is extremely narrow.
On one hand, I think terminal emulator should provides readable color 
scheme by default, including a color blind friendly version that split 
the spectrum accordingly. Or at least, color blind people would 
reconfigure there tool to do so (eg: Augie, playing Starcraft with 
special color).
On the other hand, I know that user are user. They are unlikely to even 
thing about doing this extra configuration. And terminal provider not 
providing such feature (as far as I know) Apple Terminal is not even 
able to display a properly readable blue on black background.

So lets create this wiki page and figure out if we can produce a 
consistent color scheme that provide good information for 95% of the 
humanity without throwing the last 5% under a color bus.

> Can I interest you in red_background? This I might notice.

I will give it a try, but on first look 'background' have usually very 
poor rendering on every terminal (margin-wise ) I've tried and is poorly 
fitted for word level highlighting. I'll still give it a try.

Patch

diff -r da0105aee52a -r 8e4a41b04eb9 hgext/color.py
--- a/hgext/color.py	Fri May 22 17:08:59 2015 -0500
+++ b/hgext/color.py	Fri May 22 17:20:13 2015 -0500
@@ -78,8 +78,8 @@ 
 
   # Blank so it inherits the style of the surrounding label
   changeset.public =
-  changeset.draft =
-  changeset.secret =
+  changeset.draft = magenta
+  changeset.secret = red
 
   resolve.unresolved = red bold
   resolve.resolved = green bold
@@ -329,8 +329,8 @@ 
            'diff.tab': '',
            'diff.trailingwhitespace': 'bold red_background',
            'changeset.public' : '',
-           'changeset.draft' : '',
-           'changeset.secret' : '',
+           'changeset.draft' : 'magenta',
+           'changeset.secret' : 'red',
            'diffstat.deleted': 'red',
            'diffstat.inserted': 'green',
            'histedit.remaining': 'red bold',
diff -r da0105aee52a -r 8e4a41b04eb9 tests/test-branches.t
--- a/tests/test-branches.t	Fri May 22 17:08:59 2015 -0500
+++ b/tests/test-branches.t	Fri May 22 17:20:13 2015 -0500
@@ -428,19 +428,19 @@ 
   $ hg up -C b
   2 files updated, 0 files merged, 3 files removed, 0 files unresolved
   $ hg branches --color=always
-  \x1b[0;32mb\x1b[0m\x1b[0;33m                             13:e23b5505d1ad\x1b[0m (esc)
-  \x1b[0;0ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;33m 7:10ff5895aa57\x1b[0m (esc)
-  \x1b[0;0ma\x1b[0m\x1b[0;33m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
-  \x1b[0;0mdefault\x1b[0m\x1b[0;33m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
+  \x1b[0;32mb\x1b[0m\x1b[0;33;35m                             13:e23b5505d1ad\x1b[0m (esc)
+  \x1b[0;0ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;33;35m 7:10ff5895aa57\x1b[0m (esc)
+  \x1b[0;0ma\x1b[0m\x1b[0;33;35m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
+  \x1b[0;0mdefault\x1b[0m\x1b[0;33;35m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
 
 default closed branch color:
 
   $ hg branches --color=always --closed
-  \x1b[0;32mb\x1b[0m\x1b[0;33m                             13:e23b5505d1ad\x1b[0m (esc)
-  \x1b[0;0ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;33m 7:10ff5895aa57\x1b[0m (esc)
-  \x1b[0;30;1mc\x1b[0m\x1b[0;33m                             14:f894c25619d3\x1b[0m (closed) (esc)
-  \x1b[0;0ma\x1b[0m\x1b[0;33m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
-  \x1b[0;0mdefault\x1b[0m\x1b[0;33m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
+  \x1b[0;32mb\x1b[0m\x1b[0;33;35m                             13:e23b5505d1ad\x1b[0m (esc)
+  \x1b[0;0ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;33;35m 7:10ff5895aa57\x1b[0m (esc)
+  \x1b[0;30;1mc\x1b[0m\x1b[0;33;35m                             14:f894c25619d3\x1b[0m (closed) (esc)
+  \x1b[0;0ma\x1b[0m\x1b[0;33;35m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
+  \x1b[0;0mdefault\x1b[0m\x1b[0;33;35m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
 
   $ cat <<EOF >> $HGRCPATH
   > [extensions]
@@ -456,19 +456,19 @@ 
 custom branch colors:
 
   $ hg branches --color=always
-  \x1b[0;31mb\x1b[0m\x1b[0;36m                             13:e23b5505d1ad\x1b[0m (esc)
-  \x1b[0;32ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;36m 7:10ff5895aa57\x1b[0m (esc)
-  \x1b[0;35ma\x1b[0m\x1b[0;36m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
-  \x1b[0;35mdefault\x1b[0m\x1b[0;36m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
+  \x1b[0;31mb\x1b[0m\x1b[0;36;35m                             13:e23b5505d1ad\x1b[0m (esc)
+  \x1b[0;32ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;36;35m 7:10ff5895aa57\x1b[0m (esc)
+  \x1b[0;35ma\x1b[0m\x1b[0;36;35m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
+  \x1b[0;35mdefault\x1b[0m\x1b[0;36;35m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
 
 custom closed branch color:
 
   $ hg branches --color=always --closed
-  \x1b[0;31mb\x1b[0m\x1b[0;36m                             13:e23b5505d1ad\x1b[0m (esc)
-  \x1b[0;32ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;36m 7:10ff5895aa57\x1b[0m (esc)
-  \x1b[0;34mc\x1b[0m\x1b[0;36m                             14:f894c25619d3\x1b[0m (closed) (esc)
-  \x1b[0;35ma\x1b[0m\x1b[0;36m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
-  \x1b[0;35mdefault\x1b[0m\x1b[0;36m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
+  \x1b[0;31mb\x1b[0m\x1b[0;36;35m                             13:e23b5505d1ad\x1b[0m (esc)
+  \x1b[0;32ma branch name much longer than the default justification used by branches\x1b[0m\x1b[0;36;35m 7:10ff5895aa57\x1b[0m (esc)
+  \x1b[0;34mc\x1b[0m\x1b[0;36;35m                             14:f894c25619d3\x1b[0m (closed) (esc)
+  \x1b[0;35ma\x1b[0m\x1b[0;36;35m                              5:d8cbc61dbaa6\x1b[0m (inactive) (esc)
+  \x1b[0;35mdefault\x1b[0m\x1b[0;36;35m                        0:19709c5a4e75\x1b[0m (inactive) (esc)
 
 template output:
 
diff -r da0105aee52a -r 8e4a41b04eb9 tests/test-log.t
--- a/tests/test-log.t	Fri May 22 17:08:59 2015 -0500
+++ b/tests/test-log.t	Fri May 22 17:20:13 2015 -0500
@@ -833,7 +833,7 @@ 
 
   $ hg --config extensions.color= --config color.mode=ansi \
   >  log -p -l2 --color=always
-  \x1b[0;33mchangeset:   6:2404bbcab562\x1b[0m (esc)
+  \x1b[0;33;35mchangeset:   6:2404bbcab562\x1b[0m (esc)
   tag:         tip
   user:        test
   date:        Thu Jan 01 00:00:01 1970 +0000
@@ -846,9 +846,9 @@ 
    b1
   \x1b[0;32m+postm\x1b[0m (esc)
   
-  \x1b[0;33mchangeset:   5:302e9dd6890d\x1b[0m (esc)
-  parent:      3:e62f78d544b4
-  parent:      4:ddb82e70d1a1
+  \x1b[0;33;35mchangeset:   5:302e9dd6890d\x1b[0m (esc)
+  \x1b[0;35mparent:      3:e62f78d544b4\x1b[0m (esc)
+  \x1b[0;35mparent:      4:ddb82e70d1a1\x1b[0m (esc)
   user:        test
   date:        Thu Jan 01 00:00:01 1970 +0000
   summary:     m12
@@ -1717,7 +1717,7 @@ 
   $ hg --config extensions.names=../names.py \
   >  --config extensions.color= --config color.log.barcolor=red \
   >  --color=always log -r 0
-  \x1b[0;33mchangeset:   0:65624cd9070a\x1b[0m (esc)
+  \x1b[0;33;35mchangeset:   0:65624cd9070a\x1b[0m (esc)
   tag:         tip
   \x1b[0;31mbarlog:      foo\x1b[0m (esc)
   user:        test