Idea for Building Themes for Different Editors

[obahareth]

Hey,

I remember seeing Chris Kempson's work on base16 and contributing to it (which I am unsure why he took it down but some of the community have tried to keep things living at https://github.com/tinted-theming).

The way he created a repo for templates (generic templates for each editor, that get filled in with color schemes) and schemes (color schemes) was really great. It allowed generating the color schemes for all editors.

It was easy to make a theme builder in any language because of that structure.
Here's what the tinted-theming community ended up making:

• templates
• schemes

Where a builder would go through grab all the templates, and schemes, and produce rendered templates (which are the themes for each editor).

Would it make sense to rely on that or something derived for that? Or does that not work with what's planned for Nord?

[svengreb]

Hey @obahareth 👋🏼

First, thanks for the suggestion… and also the first community-contributed discussion 🥳

Like described in the section about the history of Nord in the recent “Northern Post“ announcement, I stumbled across base16 quiet early so I've learned about their concept a long time ago.
In general automations for repetitive tasks, or almost anything that saves time and effort at the end of the day, are always a great idea, but in case of Nord we have to differentiate between the structure and type of both projects.
base16 is, as far as I know and when I read their documentation (and your new tinted-theming project) correctly, more a kind of “specification“ for color schemes that should consist of 16 colors in total. Even though Nord followed the same concept, which was more or less “dictated“ by the fact that the initial goal was a port for a terminal which is limited to 16 colors, Nord itself is “only“ a single color theme while hundreds of color palettes derived out of base16 over the time.
In short: Creating a template system for one color theme would be no benefit because there is only one source that must be adjusted when there are changes. For example, when the Nord port for “Visual Studio Code“ requires changes (e.g. adding new rules for a specific language), only this code must be changed. For base16 on the other hand this would mean that 100+ repositories must be adjusted manually because many color themes created a port for it, but thanks to their templating system it can be done in an automated way. A good example is the port for Vim which includes a bunch of color palettes like forest or savanna. For Nord's Vim port (will be migrated to the new nordtheme organization within the next weeks) there is, of course, “only“ one theme to adjust. Using a template system too would mean double overhead because the template must be adjusted and the “compiled“ theme must be pushed and published as well.
I hope this attempt of trying to describe the difference made it clear 😀

The only scenario where this could be a good use is when, in the distant future, the light/“day“ variant of Nord will be officially created and implemented for relevant ports. Even though it might be tricky to build this in a “clean“ way, to differentiate between the actual difference of contrast and color usage, it might help to reduce the effort when changes re required for all “modes“. All of this is still far away from being planned, but I'll definitely came back to you if you'd like to help to build this up 🙂

I've also seen tinted-theming some time ago (GitHub is more or less my “startpage“ 😬) and it's nice to see that the base16 community wants to keep this alive and even bring it forward.