-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea: Support full ANSI schemes with 'semantic' colors #36
Comments
Ann example of what the console 2 config would look like:
Just a direct 1-1 mapping, zero surprises. |
@kdrag0n @AFulgens @martinlindhe @aarowill I didn't want to spam all the terminal authors but I noticed that you all maintain multiple base16 terminal templates so I thought I might reach out and see if you all have any thoughts on this idea on improved ANSI 16-color support for terminals rather than the current 8 color no distinction between light/dark compromise... |
So the path forward would be to get all of the color schemes to have ansiXX variables, and then get the template repositories to swap over to using the ANSI variables rather than the baseXX variables? I'm happy to update base16-konsole once the ansiXX variables are in place in each color scheme. In your example, the comment has color 1 set to ansi 1 and the color inside the comment is blue. Isn't ansi1 red? Also, would there be a push to keep ansi1 the reddest color of the color scheme? |
There are a few parts to this:
Eventually it should be possible to write templates against these semantic aliases so you'd be able to write a terminal template which supports base16, ansi16 and other future systems using only the aiases.
I believe this was a mistake. You're right that ansi01 is red |
It'd be fine to have I would handle this all seamlessly inside the builder/resolver... |
(See my comment #65 (comment) for more details). It's fine by me to pivot to ANSI. I would suggest to undertake this as part of the migration envisioned in #44. In case this will be carried out, I would suggest to keep the original repos as archived repos and maybe linked in the new one. The generation of the orange will be an interesting dilemma, I currently cannot fathom a perfect solution, will look out for ideas by brigther minds :) |
i think it would be better than using numbered colors, to help theme-makers to not set some weird colors, like green instead of red and etc |
Well, theme makers are still free to be 'weird', but names instead of numbers does seem to make unintentional mistakes much harder to make. :-) |
I wanted to write-up my idea of how to support 16-color "classic" ANSI themes inside the Base16 banner... this involves semantic colors so that we can have all 16 of our named ANSI colors and then map them (as makes the most sense) back into the non-ANSI
baseXX
mappings - such that ANSI schemes could continue to be used anywhere that base16 is supported.The mapping isn't perfect... it's not 100% clear which ANSI colors should by default map to the old "orange hue" (
base09
) or the old brown hue (base0F
)... and the larger loss, the 8 shade BG/FG gradient now would now have to shift to only a 4 color ANSI gradient:Here is what a scheme might look like. Please ignore the rgb syntax. I'm not suggested it, it was just easiest to write up this sample without having to lookup a bunch of hexcodes.
Please note there are still only 16 colors here.
@belak and I spoke about this at length. It would require effort from template maintainers to support... mostly dealing with the 8 => 4 shade gradient reduction... but at the template level this could be supported via boolean flags:
For some app UI templates (usually app+terminal, such as Vim, Emacs, etc) this would require an investment to support both 4 and 8 color ramps... For a lot of templates (Terminal templates esp) supporting this new scheme format is even easier than what they were doing previously... since the new templates would just be mapping
ansi0 - ansi15
directly to ANSI 0 to ANSI 15, no complex mappings at all.I think an approach like this might be better than just a hard fork where we send the people who want 16 ANSI colors off to their own island to build all their own stuff... that assumes of course there are people here who are interested in actual 16 color ANSI support. For a time you might have some older templates that "don't support ANSI schemes"... it would be up to the community to fill those gaps - if they wanted ANSI everywhere".
I think going the other direction (older schemes into new templates) the ANSI palette could largely be auto-generated on the fly... so the 8 color ramp would be reduced to 4 colors (via blending) and the "hues everyone seems to use" would be mapped into the most appropriate ANSI slots and dark and light versions would be created. New templates should therefore support either BOTH (Base16ANSI and Base16) or just support ANSI and trust the auto-conversion.
So first, does anyone care about Base16 supporting 16 color ANSI light/dark/etc - just as the terminal gods originally decreed it to be? ;-)
The text was updated successfully, but these errors were encountered: