[PATCH] color: add default colors for draft and secret changes
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Tue May 26 16:35:08 CDT 2015
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.
Putting red to something as casual as 'secret' would jeopardize that.
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list