✨ Standardize Themes about codeedit HOT 3 OPEN

Somewhat theme related for highlight groups:

Many upstream Tree Sitter grammars include highlights intended to work directly with nvim (since it is probably the most used editor with tree-sitter support). Being able to keep the code edit captures in sync with nvim values could be helpful for adding languages more easily. They have a document on what they support and how they map it to their internal values:

https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups

In the The following captures are linked by default to standard group-names: section.

In Nova, you almost can never use an upstream highlights.scm file because Nova uses different capture names that map directly to Nova theme selectors. You always have to adjust the upstream one. While not the biggest issue, it would be nice to not have to manually adjust every upstream highlight file.

from codeedit.

This is some really good insight @mrsdizzie. These are my current thoughts. It is overly difficult right now to create a theme in most editors today for many developers. What if we make it easier by allowing theme creators to focus on the color palette they want to use and leave how the colors are applied up to language support extensions? Themes could have a set of color slots. Language support extensions could say, color 1 should be applied to variables, color 2 should be applied to keywords, etc. We would of course fallback to something generic. I'd love you hear you're thoughts on this!

from codeedit.

That is an interesting idea, but I'm not sure if people would end up liking that. I think people would want the colors to be consistent across all file types, and wouldn't like it if variables were pink in PHP files and brown in Javascript files because the language authors picked different color1 / color 2.

I do think it is right to focus on color palettes though. I am admittedly unfamiliar with how textmate or vscode structure themes, but my experience is that good color palettes are what people care about. For example, it seems like every editor / terminal / etc... must offer various solarized themes because those are popular and well defined colors that people like and expect to use everywhere.

Looking at examples of these implementations, it seems like most editors make this harder by not making it easy to define a palette and reference it when building the theme. As an example, I like this variant of the "Tomorrow Night" color palette:

some very basic psuedo code for a theme would be:

/* define color palette */
$red: #f2777a;
$orange: #f99157;
$yellow: #ffcc66;
$green: #99cc9b;
$cyan: #66cccc;
$blue: #6699ce;
$aqua: #cc99cc;
$pink: #cc99ce;
$brown: #ed7554;

background = brown;
variable = red;
function = aqua;
string = green;
bool = orange;

So it is easy to find a palette, define my palette in the theme, then use it for theming in a very clear way that is immediately obvious to the reader of the theme file what is happening. So I think some type of theme system that allows for this would be great.

Sublime text has something like this, though the syntax has more advanced options:

https://www.sublimetext.com/docs/color_schemes.html

But it lets you define colors as variables and then reference them later in rules.

from codeedit.