Agree with the premise, but I built a theme with a different interpretation:
https://marketplace.visualstudio.com/items?itemName=narenran...The primary difference is that my theme has an underlying assumption that colors have semantic meaning that we all implicitly understand(red = bad, yellows/oranges are action-oriented etc). So instead of color = syntax, my theme semantically maps color = intent.
• Warm colors (orange/red) for actions — throw, return, await.
• Cool colors (blue/green) for definitions and values — function names, constants, variables.
• Muted neutrals for structure and noise — punctuation, keywords like var or const
This means comments are muted, contrary to the author's proposal - imo while they are important and helpful, they're secondary to the actual code
My primary design goal was that if you open a large file and squint at it, the flow should be immediately obvious (the flow colors stand out, if you see a bunch of blues it's calling a bunch of other functions etc)
(You can see screenshots in the link)
The primary difference is that my theme has an underlying assumption that colors have semantic meaning that we all implicitly understand(red = bad, yellows/oranges are action-oriented etc). So instead of color = syntax, my theme semantically maps color = intent.
• Warm colors (orange/red) for actions — throw, return, await.
• Cool colors (blue/green) for definitions and values — function names, constants, variables.
• Muted neutrals for structure and noise — punctuation, keywords like var or const
This means comments are muted, contrary to the author's proposal - imo while they are important and helpful, they're secondary to the actual code
My primary design goal was that if you open a large file and squint at it, the flow should be immediately obvious (the flow colors stand out, if you see a bunch of blues it's calling a bunch of other functions etc)
(You can see screenshots in the link)