[PATCH] color: add default colors for draft and secret changes

[Pierre-Yves David]

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

-- 
Pierre-Yves David