thertzlor / semantic-rainbow

A maximalist VSCode color theme for semantic highlighting featuring bold colors and subtle distinctions.

Hello there. I do code things. I like to work on things that are niche and weird but still useful. Everything here is maintained in my free time.

Languages I like to use:

• TypeScript/JavaScript
• lua
• Python

semantic-rainbow's Issues

Better syntax highlighing for Bash

Just installed your theme in VS Code, and opened my Bash code, and it looks cool, but doesn't look, well, very rainbowy:

If Bash has Semantic Highlighting, maybe you could add some syntax highlighting for it? 😃

light theme

is there any plan to release a light theme version in the near future?

Rust Support

Couldn't find a better place to add a feature request or gauge interest...

I know the readme suggests adding support for more language-specific features. I'm simply here to ask whether rust is of particular interest to this project, be it implemented by the current maintainer or a new maintainer such as myself. If supporting Rust is something that you are particularly interested in, then I'm interested in having a discussion about which language features should be considered for semantic coloring, the feasibility of each, and related topics.

Disable italics?

Hey! I found this theme the other day and actually love it. Thanks!

I'm curious why "Any time any value is declared or initialized, the token will be displayed in italics."
Is there a way to disable this in settings.json?

Thanks again!

Questions and feedback about extending the project

Hi. I'm a fan of semantic highlighting and since LSP started supporting it I have been amazed by how well some editors can colorize code.

Your project went really far with it, maybe even too far (in terms of combinations - the 336 colors). I would like to extend it and provide some feedback. Please note that I work almost exclusively with C++ and my thoughts are thus oriented for it. I'm also heavily used to Vibrant Ink theme so if possible, I would contribute another color pallete as I don't feel confident in extending existing color scheme. Your color scheme is original and I suspect most people would be used to themes based on already-popular palletes like Monokai. Thus, I propose to add an ability for multiple color schemes (and language-specific themes if that's possible).

Notice any contexts in which the existing syntax highlighting looks bad or incomplete?

In C++ ; is barely visible. Kinda annoying because this language is full of symbols. I assume the same happens for C because both are very often backed by the same tooling and there is only one LSP implementation.

Know any language with Semantic Highlighting that this theme could support better?

C++ is complex enough that it's LSP server (clangd) uses many non-standard names for token types and modifiers.

Here is a list from clangd-15.0.2 LSP initialize call:

types:
'variable', 'variable', 'parameter', 'function', 'method', 'function', 'property', 'variable', 'class', 'interface', 'enum', 'enumMember', 'type', 'type', 'unknown', 'namespace', 'typeParameter', 'concept', 'type', 'macro', 'comment'
modifiers:
'declaration', 'deprecated', 'deduced', 'readonly', 'static', 'abstract', 'virtual', 'dependentName', 'defaultLibrary', 'usedAsMutableReference', 'functionScope', 'classScope', 'fileScope', 'globalScope'

Some extra feedback (C++-centric):

• Some of the token types/modifiers are unreachable (e.g. interface) because C++ doesn't differentiate between classes and interfaces - it allows to write both and everything in between because it puts practically no limits on multiple inheritance and where/when a function can be virtual and/or abstract. I can call such situations a "color waste" because the interface token type simply won't be reported and any color assigned to it is just wasted. Move the focus to function calls instead.
• Some colors for some modifiers are unnecessary, e.g. defaultLibrary practically delivers no information because 1) C++ standard library is pretty small compared to other languages 2) The standard library is hardly ever imported to global scope which means all names from it will be prefixed with std::
• IMO there is a significant opportunity to exploit custom token types/modifiers reported by clangd: usedAsMutableReference can be used to highlight out parameters and dependentName is a color-game-changer for templates.
• IMO there are too many colors. Instead of using so many shades for different token modifiers, I would reserve a significant portion of them to style each variable in a different shade. Sadly VS Code does not support this feature, but I would reserve it for my own use - currently I'm experimenting with using clangd to highlight code I would put on my website, which has the potential to look far richer than any highligher for websites. Ideally I would contribute my theme based on experiments with clangd-based-rendering of C++ code on my website - both are using LSP for highlight.

Diff comments hard to read

Describe the bug
In the source code diff view, it's difficult to read comments on newly added lines, and new comments added to existing lines.

To Reproduce
Add a comment and open the diff view.

Expected behavior
Newly added comments should be legible in diff view.

Screenshots