Allow color index to be in the range [0, 15] for the 256 variant? (v3)

[ghost]

Hi, again. I'm actually making quite good progress on learning colortemplate and on the color scheme, but I have encountered one small issue that's not a bug, but a decision I would like to question. The original base16 templates actually choose to use some colors in the [0, 15] range for the 256 'variant.'

I could use ~ and gx to insert approximations of the true color/gui variant (very handy, by the way), but I'm keen to stay faithful to the original implementation. Is there a reason for declining to build with the message:

[Colortemplate] Build failed: Xterm color index out of range: 0 (must be between 16 and 255) (line 9, byte 198).

or is it more a philosophical choice? Using approximations is an acceptable alternative, but from what I can see, it is currently impossible to—at the very least—reproduce the original implementation given this seemingly arbitrary limitation.

[ghost]

~I left my desk, but I imagine I just failed to test excluding the 256 variant altogether when both 16 and 256 variants are the same…~

[ghost]

Just tested: my assumption was incorrect. The syntax seems to require a 256 value first and that must be in the range [16, 255].

Some examples of rejected entries:

Color: myblue #abcdef Blue
Color: myblue #abcdef 4
Color: myblue #abcdef Blue Blue
Color: myblue #abcdef 4 4

Edit: It may have to do with the integer requirement in combination with the libcolor function checks; probably need to check which function to use (if it's in [0, 15] use the cterm function otherwise the xterm function)...

[lifepillar]

That's by design. A color scheme that has a color in 0–15 will produce unpredictable results unless the terminal colors are set to predefined values (which is a requirement for Base16). This severely restricts the scope for using your color scheme to terminals with some specific settings.

Mixing the terminal-dependent range 0–15 with the more predictable (though not uniquely defined) 16–255 range of colors makes your color scheme even less usable. AFAIK, Base16 requires the user to run a script to change the terminal palette—colors 16–21 in particular—which works only in some terminals.

Colortemplate v3 was designed having in mind color schemes that are proposed for inclusion in Vim, so some bad choices such as those above have been forbidden. It wouldn't be too difficult to add an option to lift such restriction, though.

[lifepillar]

The syntax seems to require a 256 value first and that must be in the range [16, 255].

A color definition has three values:

• a hex value, used for GUI and true-color terminals;
• a “base-256” (or xterm) value, that is, a value in the range 16–255 or a color name in v:colornames. This is used for terminals with 256 colors. As the Xterm palette is similar, though not identical, across terminals, this gives the most predictable results for terminal not supporting true colors. That wouldn't be the case if colors 0–15 were allowed, too.
• a “base-16” or ANSI value, that is, a value in the range 0–15 or a color name among those listed in :help ctermc-colors. This range entirely depends on the terminal settings, and is used when t_Co is set to a value less than 256.

[ghost]

Aren't the ANSI colors a subset of the xterm colors? I would imagine you could use "Black," for example, in a palette using xterm colors.

[lifepillar]

Sure you can. The (opinionated, if you want) stance of Colortemplate is that you shouldn't, because that Black might be white or pink.

But there is no technical reason to prevent that. I will add an option to relax the restriction.

[ghost]

Okay, now I understand—thanks for bearing with me. I think the "opt in at your own peril" solution is great. I was unaware of that property of some terminals limited to ANSI colors.

[lifepillar]

The current head of the v3 branch should allow you to use any value between 0 and 255. Feel free to reopen if that does not work as expected.