Setting ANSI Colors

[bizb]

I'd like to set ANSI colors like in xterm (to make the default colors
easier on the eyes)

XTerm*color0: black
XTerm*color1: #9e1828
XTerm*color2: #aece91
XTerm*color3: #968a38
XTerm*color4: #414171
XTerm*color5: #963c59
XTerm*color6: #418179
XTerm*color7: gray
XTerm*color8: gray40
XTerm*color9: #cf6171
XTerm*color10: #c5f779
XTerm*color11: #fff796
XTerm*color12: #4186be
XTerm*color13: #cf9ebe
XTerm*color14: #71bebe
XTerm*color15: white

-Jeff

[Andy Koppe]

> I'd like to set ANSI colors like in xterm (to make the default colors
> easier on the eyes)

I take it you'd be happy with a configfile-only way for doing this?

E.g.:

Black=0,0,0
Blue=40,24,158
...
BrightWhite=255,255,255

Andy

[Jeff Bisbee]

You betcha!

If you are going to use color names (like in your example), it would
nice to know how ANSI 0-15 map to those colors. I'm sure its
"standard", but as a dumb user I just don't know what that standard is
;)

BTW, mintty is the best thing since sliced bread. I've been looking
for a solution like this for awhile and keeps me for having to install
xorg just to get stupid xterms

Jeff Bisbee / jbi...@gmail.com / jbisbee.multiply.com

[Andy Koppe]

> If you are going to use color names (like in your example), it would
> nice to know how ANSI 0-15 map to those colors.  I'm sure its
> "standard", but as a dumb user I just don't know what that standard is

It'd be in the soon-to-be-added man page. I've entered issue 62 for
this.

Meanwhile, you could hack the ANSI colours directly in the source.
They're hard-coded around line 900 of wintext.c:

static const COLORREF
ansi_colours[16] = {
0x000000, 0x0000BF, 0x00BF00, 0x00BFBF,
0xBF0000, 0xBF00BF, 0xBFBF00, 0xBFBFBF,
0x404040, 0x4040FF, 0x40FF40, 0x40FFFF,
0xFF4040, 0xFF40FF, 0xFFFF40, 0xFFFFFF
};

Andy

[Taft]

I tried changing these colors in the code and compiling. I had two
issues come up. First, I got a few compilation warnings when
compiling winclip.c. They looked like this:

winclip.c: In function `dt_release':
winclip.c:433: warning: passing arg 1 of `InterlockedDecrement'
discards qualifiers from pointer target type

So I removed the -Werror from the Makefile and went on... However it
seems as though not all of the colors I put in ansi_colours took
effect. In particular, I couldn't seem to effect the value of the
blue or light/bold blue ansi colors. For example, I tried this:

static const COLORREF
ansi_colours[16] = {

0x000000, 0x404040, //black, blue
0x00CC00, 0x00CCCC, //green, cyan
0xEE0000, 0xCC00CC, //red, purple
0xBFBF00, 0xBFBFBF, //yellow, light gray
0x404040, 0x404040, //gray, light blue
0x40FF40, 0x40FFFF, //light green, light cyan
0xFF4040, 0xFF40FF, //light red, light purple
0xFFFF40, 0xDFDFDF //light yellow, white
};

And rather than seeing grey text for blue/bold-blue, I saw the same
old blue text that I started with. I'm not sure if this is an
artifact of the previous warnings but doesn't really seem like it.
Just a heads up as it seems like you'll be working on this bit of code
for the 0.3.8 release (hooray!)

BTW, excellent work on this project. I really am impressed with the
results so far.

[Andy Koppe]

> I tried changing these colors in the code and compiling.  I had two
> issues come up.  First, I got a few compilation warnings when
> compiling winclip.c.  They looked like this:
>
>    winclip.c: In function `dt_release':
>    winclip.c:433: warning: passing arg 1 of `InterlockedDecrement'
> discards qualifiers from pointer target type

What compiler and version where you using? And have you got a recent
install of Cygwin? It compiles fine here both with gcc-3.4.4 and
gcc-4.3.2. Seems you're getting an InterlockedDecrement prototype
without 'volatile' on the argument type.

> So I removed the -Werror from the Makefile and went on...  However it
> seems as though not all of the colors I put in ansi_colours took
> effect.  In particular, I couldn't seem to effect the value of the
> blue or light/bold blue ansi colors.  For example, I tried this:
>
> static const COLORREF
> ansi_colours[16] = {
>  0x000000, 0x404040,  //black, blue
>  0x00CC00, 0x00CCCC,  //green, cyan
>  0xEE0000, 0xCC00CC,  //red, purple
>  0xBFBF00, 0xBFBFBF,  //yellow, light gray
>  0x404040, 0x404040,  //gray, light blue
>  0x40FF40, 0x40FFFF,  //light green, light cyan
>  0xFF4040, 0xFF40FF,  //light red, light purple
>  0xFFFF40, 0xDFDFDF   //light yellow, white
> };
>
> And rather than seeing grey text for blue/bold-blue, I saw the same
> old blue text that I started with.  I'm not sure if this is an
> artifact of the previous warnings but doesn't really seem like it.

Perhaps you're actually using a blue from the extended color palette,
i.e. xterms 6x6x6 color cube? Otherwise, no idea what might be going
on there.

> BTW, excellent work on this project. I really am impressed with the
> results so far.

Thanks!
Andy

[Andy Koppe]

Taft wrote:
> static const COLORREF
> ansi_colours[16] = {
>  0x000000, 0x404040,  //black, blue
>  0x00CC00, 0x00CCCC,  //green, cyan
>  0xEE0000, 0xCC00CC,  //red, purple
>  0xBFBF00, 0xBFBFBF,  //yellow, light gray
>  0x404040, 0x404040,  //gray, light blue
>  0x40FF40, 0x40FFFF,  //light green, light cyan
>  0xFF4040, 0xFF40FF,  //light red, light purple
>  0xFFFF40, 0xDFDFDF   //light yellow, white
> };

I realised what happened there: the entry you thought was blue is
actually red, because COLORREFs are actually encoded as BGR. (Due to
little-endianness they'll end up as RGB in memory.)

Anyways, I've implemented this on SVN trunk, would be great if you
could give it a try. (I'll leave 0.3.x in peace now, apart from
bugfixes, so this will be in 0.4.0).

svn checkout http://mintty.googlecode.com/svn/trunk/ mintty-trunk

Here are the default settings to get you started.

AnsiBlack=0,0,0
AnsiRed=191,0,0
AnsiGreen=0,191,0
AnsiYellow=191,191,0
AnsiBlue=0,0,191
AnsiMagenta=191,0,191
AnsiCyan=0,191,191
AnsiWhite=191,191,191
AnsiBoldBlack=64,64,64
AnsiBoldRed=255,64,64
AnsiBoldGreen=64,255,64
AnsiBoldYellow=255,255,64
AnsiBoldBlue=64,64,255
AnsiBoldMagenta=255,64,255
AnsiBoldCyan=64,255,255
AnsiBoldWhite=255,255,255

Andy

[Andy Koppe]

> Anyways, I've implemented this on SVN trunk, would be great if you
> could give it a try. (I'll leave 0.3.x in peace now, apart from
> bugfixes, so this will be in 0.4.0).

Hang on, the ANSI colours can already be changed using the Linux "set
palette" escape sequence: ESC ] P nrrggbb
The lowercase letters are hexadecimal digits, with n for the ANSI
color number and rr, gg, and bb for the red, green and blue
components.

E.g.:

echo -e "\e]P3FF0000"

changes yellow to red.

I'll revert the change in the interests of minimalism. :)

Sorry,
Andy

[Chris Sutcliffe]

> Hang on, the ANSI colours can already be changed using the Linux "set
> palette" escape sequence: ESC ] P nrrggbb
> The lowercase letters are hexadecimal digits, with n for the ANSI
> color number and rr, gg, and bb for the red, green and blue
> components.
>
> E.g.:
>
> echo -e "\e]P3FF0000"
>
> changes yellow to red.
>
> I'll revert the change in the interests of minimalism. :)

Hrm... can it handle the colour above 0 - 7 (i.e. the bold colours)?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

[Chris Sutcliffe]

Man do I feel stupid...

>> echo -e "\e]P3FF0000"
>>
>> changes yellow to red.
>

> Hrm... can it handle the colour above 0 - 7 (i.e. the bold colours)?

Yes it does.... use hex:

echo -e "\e]PcFF0000"

Changes bold blue to red.

Sorry for the noise.

[Taft]

Works like a charm! Thanks.