Is there a particular reason why there's currently not a semantic token type for decorators or attributes? If not, would it be possible to create one?
It doesn't seem like TypeScript has one applied today:

It'd be great to see a semantic token type for this.
For PowerShell it would be very useful to differentiate between Types and Attributes:

In Java, there is also annotation type.
e.g.
@SuppressWarnings("restriction")
public class Foo {
// ...
}
Just FYI, Java language server defines a new annotation type for the case. And VSCode Java extension also declares custom token types , e.g. annotation inherits from standard token type type, to leverage highlighting from most themes.
@Eskibear thanks! I'd still love to see a specific `SemanticTokenType so that the built in themes to VS Code could include a specific color for Decorator/Attriubute/Annotation.
@Eskibear thanks! I'd still love to see a specific `SemanticTokenType so that the built in themes to VS Code could include a specific color for Decorator/Attriubute/Annotation.
@TylerLeonhardt Just to be clear, the protocol declaring it has no bearing on what happens in VS Code. Code changes would still be required on that end to support this.
@rcjsuen yes but it's more likely that VS Code would be willing to include coloring in their default themes for a semantic token for Decorator/Attriubute/Annotation defined by LSP.
They would be less inclined to colorize a PowerShell/.NET specific custom semantic token type for "Attribute".
Since a lot of languages have this concept (Decorator/Attriubute/Annotation) it would make sense to have it included in the LSP so that editors could generically support colorizing it.
@rcjsuen yes but it's more likely that VS Code would be willing to include coloring in their default themes for a semantic token for Decorator/Attriubute/Annotation defined by LSP.
Looks like that has already been raised now that I've done some digging (https://github.com/microsoft/vscode/issues/97063#issuecomment-673947951).
One thing to note is that the list of tokens is not fixed in the protocol. If a client announces an additional token a server can still use it even if it is not defined in the LSP protocol.
One thing to note is that the list of tokens is not fixed in the protocol. If a client announces an additional token a server can still use it even if it is not defined in the LSP protocol.
But this mechanism strictly couples clients and servers and makes it essentially impossible to write a generic client implementation.
@dbaeumer please see my response to that a couple comments up: https://github.com/microsoft/language-server-protocol/issues/1067#issuecomment-673115647
I will coordinate this with VS Code.