Veykril
commented
3 years ago This is certainly something that would be nice, we did something similar for punctuation already. See https://github.com/rust-analyzer/rust-analyzer/issues/6152 and the corresponding PR https://github.com/rust-analyzer/rust-analyzer/pull/6238.
Note that the LSP doesn't define inheritance relationships for semantic tokens, so this will cause general operator styling to not work unless the client defines such relationships itself. In case for VSCode this is possible to specify and we already do that for punctuation, so this would have to be adjusted for this to cover the new operator tokens then.
Currently, rust-analyzer categorizes all operators as being of "operator" semantic token type. While this is very much according to the spec, it does make coloring different operators different colors impossible in semantic highlighting, which was not (and still is not) a problem with non-semantic syntax highlighting. Themes and token color customization settings cannot be used to work around this problem. The
keyword.operatortextmate blanket matching rule is used for operators in semantic highlighting, and such a rule is defined in the intrinsic base themes supplied with VS Code. Since semantic token coloring rules always override textmate coloring rules when semantic highlighting is enabled, this means that all operators are colored the same color according to some token coloring rule.My proposal is to add custom semantic token modifiers to the different kinds of operators so that token coloring rules can selectively select some operators but not others, and color them as desired. I am not aware of any particular LSP language server that does this yet, but I would not be surprised to find out about ones that do this or are in the process of implementing such modifiers.