ANSI 8 (7?) scheme system

[JamyGolden]

Moving discussion here from: tinted-theming/schemes#65 (comment) where I mentioned my thoughts on this and @clach04 had been thinking about something similar.

Here is some minor context:

I've been considering looking into creating another scheme system taking in ANSI 00 to 07. Then to also make it compatible with base16 and base24 templates by generating base00-base17 colours. That way the themes would be more consistent too. Generating the schemes would also be easy using base16/base24 schemes. Anyway not anything solid, just something I'm pondering.

The thoughts I had are: how can we minimise the colours in a scheme and maximise what we get out in a template. Using the ANSI 8 colours we can easily generate base16 and base24 themes and also opens the option of coming up with even 3 sets of colours per scheme (dim red and bright red generated from red for example).

Just opening this up here for thoughts and ideas.

[j-c-m]

Timely I guess, my experiment in #139, was kind of the reverse - making a better ansi mapping from existing base16.

The overlap I am seeing is on the question where do you put the "dark red / brown" and "orange" color in ANSI, \33m (yellow) (3) has some tradition holding brown and orange.

Another consideration was the grayscale, I think generating it across 232-255, transitioning from ansi 0->7->15 (15? possibly being generated based on 0->7). I don't like the current mapping in 256 color space 16-21, especially for the grayscale.

[clach04]

I have a quick and dirty prototype for this to demo the concept, as part of clach04/terminal_style_toolkit#28

It generates:

NOTE the pink blocks are TODO colors, i.e. not defined:

"base09": "FIXME09",  # (Orange) 
"base0F": "FIXME0F",  # (Dark Red or Brown)
"base10": "FIXME10",  # (Darker Black) 
"base11": "FIXME11",  # (Darkest Black)

And the variant is hard coded.

Output "yaml" - json is valid YAML 😉

{
    "author": "clach04",
    "name": "sample ansi8",
    "palette": {
        "base00": "#000000",
        "base01": "#1f1f1f",
        "base02": "#3e3e3e",
        "base03": "#5d5d5d",
        "base04": "#7c7c7c",
        "base05": "#9b9b9b",
        "base06": "#bbbbbb",
        "base07": "#dadada",

        "base08": "bb0000",
        "base09": "#FFA8EB",
        "base0A": "bbbb00",
        "base0B": "00bb00",
        "base0C": "00bbbb",
        "base0D": "4a4aff",
        "base0E": "bb00bb",
        "base0F": "#FFA8EB",

        "base10": "#FFA8EB",
        "base11": "#FFA8EB",
        "base12": "#ff0000",
        "base13": "#ffff00",
        "base14": "#00ff00",
        "base15": "#00ffff",
        "base16": "#9494ff",
        "base17": "#ff00ff"
    },
    "system": "base24",
    "variant": "dark"
}

From 8 ANSI colors, using black as background and white as foreground - reverse support not implemented (yet).

I'm not super happy with the bright color results, but it's a start 😄 .

This proof of concept relies on a json input file format based on Putty - but it wouldn't be too hard to pull this out standalone and making a pure Base24/Base16 yaml based one.

[clach04]

The base00-base07 is a dumb spread algorithm I knocked up. It might make sense to not use black and white as input and take in min/max values then derive white and black. I.e. specify 6 ANSI colors and start/end for gray scale range.

The brighten/lighten is foxyfy() from pywal - pywal has other methods for color alteration.

1. I have no ideas for how to deal with base09/Orange
2. For base0F I think we could darken base08.
3. base10/base11 could potentially be considered additional colors in base00-base07 - I..e.

base11  # darkest
base10
base00
base01
base02
base03
base04
base05
base06
base07  # lightest

so range base11 to base07 could be the input range + 6 ANSI colors.

[JamyGolden]

I think the dark and the light values used in this hypothetical scheme system should be equivalent to base00 for black, but base05 for light since we’re providing the “normal” colours and not black along with bright white.

We could figure out an orange based on the yellow.

I’m not really sure about base10 and base11. We could darken the “black” provided but it might be unusable. Right now I don’t think we use base10 or 11 anywhere in our templates, especially since they aren’t given any meaning in the spec.

[j-c-m]

This could be long, but here is my perspective, this is where I am coming from. I am here again now because I wanted to update my local base16-shell & base16-vim, years ago I did a lot of optimizations to make the shell faster. I want my vim and my terminal to look similar, and non base16/tinted aware terminal apps to look reasonable. I basically was going to remove the 16-21 256colorspace re-map in the template and update everything...

base9 ?

required:

base16	color	ansi
base00	black	0
base05	white/foreground	7
base08	red	1
base0A	yellow	3
base0B	green	2
baseOC	cyan	6
baseOD	blue	4
baseOE	magenta	5
base07	bright white	15

re-ordered now:

base9	color	ansi	base16
base00	black	0	base00
base01	red	1	base08
base02	green	2	base0B
base03	yellow	3	baseoA
base04	blue	4	base0D
base05	magenta	5	base0E
base06	cyan	6	base0C
base07	white	7	base05
base08	bright white	15	base07

for mapping the rest to base16, we have a default brown (base0F) and orange (base09), we tint them in the builder with base07 & a default color tbd.

for the grayscales have the builder generate between the range of base00-base07 for (base16) base01, base02, base03, base04, mix base07-base08 for (base16) base06

I think its possible we could generate bright white, but I think its important in the spec to have "the brightest we want this scheme to get color, which is base08 (base07-base16)

To make this all work the builder needs to get smarter, I think work should be done on the builder to always generate the full highest spec rgb table, ie base24 right now.

My thoughts on translating base16 to base24 in the builder, is to slightly brighten for dark themes, and slight darken for light themes what accounts for ansi 9-14.

When applying templates created, base9 should always apply as base24, base16 should always apply only as base16 (with configuration option for 24), base24 as base24. Essentially the default honors base16, but assumes base9 we want generated base24.

Then also be prepared to break backwards compatibilty, because its confusing enough with base16%= and base24%= floating all over, tinted-theme=base9-simple , tinted-theme=base16-3024, tinted-theme=base24-3024-day, tinted-force24=true , etc deperate all these old config variables. (oh and remove the 16-21 256 colorspace re-map in tinted-shell ;)

Hope that makes some sense, its left to finding a decent algorithm for rgb color manipulation in the rust builder and I think this could be hammered out.

[j-c-m]

This is where I am going at least with tinted-shell, you can do the magic in mustache but would be cleaner if builder just did the base16 to base24 mappings.

j-c-m/tinted-shell@e738716

https://github.com/j-c-m/tinted-shell/blob/e73871618d30d0144e44711a24d796c319ae349e/templates/tinted-shell.mustache

This also had me thinking maybe we should just do the 1:1 mapping of base16->base24 in the builder w/o trying to brigthen/darken the mapping to simplify templates generation.

[j-c-m]

Having completed a bunch of work today with tinted, my opinion is base24 should probably not exist in its current state.

I like the focus on this new "base8or9", then extend base16 (optional support for 6 more bright/dim terminal colors, ansi 9-14), I think what made base16 so popular was the clear cut "text editor" mappings, base24 is too terminal/ansi centric.

Internally the builder would generate base16(+6) rgb codes for base8o9, map 1:1 for existing base16, explicitly defined from base24, now convereted back to base16(+6)

[j-c-m]

https://github.com/j-c-m/tinted-home-base16/blob/base16-opt6/styling.md

[j-c-m]

all seems very possible

[JamyGolden]

Nice. Yeah it's definitely possible. I created https://github.com/tinted-theming/tinted-scheme-extractor-rs which creates a base16 or base24 scheme based on the colours of an image. Creating all of this is relatively trivial imo. There will be some edgecases where things need to be adjusted to work with specific colour ranges, but nothing that we should worry about the technicalities.

base24 should be a superset of base16, so it has the same focus with extra bright colours to use by templates, so I don't think it is overly terminal focused compared to base16. While the base24 extra colours don't have "areas" set where one should use them, when creating templates I've typically used the bright variants for where I would use the base16 colours except I want some kind of accent.

[j-c-m]

Here's my proof of concept demo for ansi8, "upsampling" all the way to base16+opt6, it works great.

ansi8	color	ansi	base16
ansi0	black	0	base00
ansi1	red	1	base08
ansi2	green	2	base0B
ansi3	yellow	3	base0A
ansi4	blue	4	base0D
ansi5	magenta	5	base0E
ansi6	cyan	6	base0C
ansi7	white	7	base05

base16+opt6

Color	base0X	ANSI	Terminal	Text Editor
	base00	0	Black (Background)	Default Background
	base01	18	(Darkest Gray)	Lighter Background (Used for status bars)
	base02	19	(Dark Gray)	Selection Background
	base03	8	Bright Black (Gray)	Comments, Invisibles, Line Highlighting
	base04	20	(Light Gray)	Dark Foreground (Used for status bars)
	base05	7	White	Default Foreground, Caret, Delimiters, Operators
	base06	21	(Lighter White)	Light Foreground
	base07	15	Bright White	The Lightest Foreground
	base08	1	Red	Variables, XML Tags, Markup Link Text, Markup Lists, Diff Deleted
	base09	16	(Orange)	Integers, Boolean, Constants, XML Attributes, Markup Link Url
	base0A	3	Yellow	Classes, Markup Bold, Search Text Background
	base0B	2	Green	Strings, Inherited Class, Markup Code, Diff Inserted
	base0C	6	Cyan	Support, Regular Expressions, Escape Characters, Markup Quotes
	base0D	4	Blue	Functions, Methods, Attribute IDs, Headings
	base0E	5	Magenta	Keywords, Storage, Selector, Markup Italic, Diff Changed
	base0F	17	(Dark Red or Brown)	Deprecated, Opening/Closing Embedded Language Tags, e.g. <?php ?>
			optional	sample from base##->opt## if not supplied by scheme
	opt08	9	Bright Red	NA
	opt0A	11	Bright Yellow	NA
	opt0B	10	Bright Green	NA
	opt0C	14	Bright Cyan	NA
	opt0D	12	Bright Blue	NA
	opt0E	13	Bright Magenta	NA

Notes:

• These are just guidelines and will most often provide best results when the they are followed.
• Items in parenthesis in the Terminal column do not have an identified terminal use and are a more generic color description.
• Most terminals allow to set extended ANSI colors, but not all. It can't be assumed that the extended ANSI colors are set when using a tinted-theming terminal template theme.
• opt colors will typically be brighter for dark themes and darker for light themes.
• opt colors not specified will be sampled from corresponding base colors and made brighter (0.1) and less saturated (-0.2) for dark themes, the opposite for light themes (-0.1,0.2) respectively.