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