Use 4-bit ANSI codes for base16 theme

[sharkdp]

This PR changes the behavior for the base16 theme.

So far, we would print ANSI escape codes like

\x1b[38;5;__m

which require a terminal with 256 color support.

With this change, we use "4-bit" codes

\x1b[__m

like \x1b[31m for "red".

There is no change for the ansi-dark and ansi-light themes.

Unfortunately, ansi_term does not support "bright" versions of these colors (see table here). We currently fall back to the non-bright versions.

closes #865

[sharkdp]

@mk12 FYI

[mk12]

@sharkdp I think this should remain "ANSI palette number." The base16 numbers are mapped onto the ANSI palette as follows by base16 terminal templates (e.g. iTerm2):

ANSI	Base16
0	0
1	8
2	B
3	A
4	D
5	E
6	C
7	5
8	3
9	9
A	1
B	2
C	4
D	6
E	F
F	7

The RR values in this file are from the first column, not the second.

[mk12]

Unfortunately, ansi_term does not support "bright" versions of these colors (see table here). We currently fall back to the non-bright versions.

This makes the base16 theme use the wrong colors :/ For example I think line numbers will become green instead of dim grey because 0x0B (ANSI bright green, but in base16 it means dim grey) is going to 0x02 instead.

Could we change ansi_light & ansi_dark to use the 0f alpha encoding, and leave base16 with 00? They seem more appropriate for this since they don't use the bright colors.

[sharkdp]

Thank you for reviewing this (and sorry if I accidentally broke some of your work 😨).

This makes the base16 theme use the wrong colors :/ For example I think line numbers will become green instead of dim grey because 0x0B (ANSI bright green, but in base16 it means dim grey) is going to 0x02 instead.

I'm not sure I can follow. Line numbers in bat are drawn with the gutterForeground color of the respective Sublime Text scheme. For the base 16 scheme, that would be:

<key>gutterForeground</key>
<string>#0800000f</string>

With my code change, this will be mapped according to Color::Black:

    } else if color.a == 0x0f {
        match color.r {
            0x00 => Color::Black,
            0x01 => Color::Red,
            0x02 => Color::Green,
            0x03 => Color::Yellow,
            0x04 => Color::Blue,
            0x05 => Color::Purple,
            0x06 => Color::Cyan,
            0x07 => Color::White,
            // TODO: the following should be high-intensity variants of
            // these colors ("bright black", "bright red", ...).
            0x08 => Color::Black,
            0x09 => Color::Red,
            0x0a => Color::Green,
            0x0b => Color::Yellow,
            0x0c => Color::Blue,
            0x0d => Color::Purple,
            0x0e => Color::Cyan,
            0x0f => Color::White,

On my terminal emulator base16 scheme, it looks like this:

[sharkdp]

Let me know if you think this PR should be reverted.

[mk12]

Your screenshot looks fine, but I’m not sure how it’s working — I would have expected Color::black to blend in with the background. I’ll try it out on the weekend.

And don’t worry, I know you weren’t intending to break anything :) If I find any colors that aren’t working, I can make a PR to do as I mentioned before (use this 0x0f trick on ansi_light and ansi_dark instead). Or maybe I’ll just try adding bright support to ansi_term if it’s not too hard. In principle I think it is better for ansi_light, ansi_dark, and base16 to all use the 4 bit codes.

[mk12]

Yeah, this makes the line numbers unreadable for me (I've selected a few lines to show that they're actually there, just blended with the background):

I have fixed this in #972 while preserving your fix to #865. Though users with that issue should be using ansi-light or ansi-dark, not base16. Base16 is really a specialized color setup for people who want all their applications to use a consistent palette, and is only incidentally similar to the number of colors that non-256-color terminals support.

[ches]

I can corroborate the breakage, it's my primary theme and I've pinned bat to 0.13 for now—came to report it when I saw @mk12's PR, thanks for the fix!

[sharkdp]

Fixed in v0.15.1