I use syntax highlighting is to... well, highlight important things.
If someone disagrees with that assumption, the palette will not work for them.
Some existing examples are "warning squiggles" added by IDE integrated linters, as well as language-level syntactic markers for "here be dragons" parts like Rust’s `unsafe {}` that can be highlighted by standard syntax highlighters (as an aside, it occurs to me that for simplicity’s sake most syntax coloring is in fact merely lexical coloring, but I digress…)
It seems to me that many color schemes these days choose to render comments in grayed-out, low-contrast colors. I find this to defeat the purpose of comments and maintain the unfortunate notion that they are something nearly redundant. A properly written comment tells me something nonobvious and should be displayed prominently rather than faded into obscurity!
With the situations you describe, you can write tree-sitter queries to make unsafe code highlighted in a different color, for instance, or highlight specific anti-patterns.
In this area, as a novice coder, I am absolutely out of my depth though, so I’d have to defer to actual experts for the implementation.
Someone else brought up a similar point on comment emphasis but I’ve seen the opposing opinion too.
So I find the trend for color schemes with many lexical types colored differently, unpleasant to the eye and usually of little practical advantage.
The more different things we try to distinguish in a color theme, the harder it is to produce a comfortable aesthetic and the harder it is to make things which should advance or retreat from the eye, to do so.
Keywords can take pleasant color slots which are not the most easily read, because their color confirms they are typed correctly. There is little advantage and much overhead in theming keywords of different types differently. Strings types can all share a hue similarity with small difference to help notice single or double quotes etc. Escaped chars are good to stand out a bit, within the appropriate quotation hue. Comments should be in color range which retreats from the eye a little and is well separated from the executable hues.
I feel its all window dressing, plain text is just a little harder to scan for things than nicely syntax highlighted. Busy, un-finessed syntax highlighting is more of a quirk to be tolerated than it is a comfort.
Control flow & operators etc are dark red, identifiers more or less neutral, and top level functions accented. This makes it easy to scan quickly, because you want to be able to navigate a file quickly without getting bogged down in a rainbow of color and then slow down down to understand the tricky bits.
Just reading the comments provided a lot of insight on things like accent color usage.
Im very used to warm colors now so Gotham is the closet spiritual thing in VSCode to this.
[1] https://github.com/sjl/badwolf/ https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim
I suspect a useful tool would be one that starts with vision science based uniformities but that then enables personalised tweaks, ideally with vision science guidance.
To your point, it matters what kind of tokens a colour is going to be used for. If they’re small (eg operators), then the effective perceptual uniformity is broken. They’ll be less conspicuous. Being brighter and more saturated would probably help. Perceptual salience can be tricky, and it’s useful to remember that our colour vision is flawed and finicky. Similarly but inverted for large tokens such as class names.
Beyond that, once you start modulating saturation and brightness to get a nicer look, you’re back into a 3D colour space where the evenly spaced hues idea starts to make less sense, or so I suspect.
Nonetheless, cool work! I would have liked to do the same if I was able!
Given the way that themes are currently implemented, I thought making this simplification was reasonable.
If you’re not dead set on the hard constraints I was aiming for, the tool linked below looks great for your purpose though, except it should really be using OKlab instead of CIELab.
Part of being able to skim code is to pick out the key words or symbols that denote control flow, important (exceptional, even) cases, etc. The dizzying array of identifiers is less important when trying to skim and pick apart the general "feel" of code quickly.
In this pallette, at least with python, the identifiers are red, everything is "flat" (due to the perceptual brightness) and thus nothing really sticks out or gives me "grit" to hold on to when navigating around.
I could be wrong. This is just my hypothesis going in.
Cool project nonetheless, I love the idea to use color science as the basis for this.