@matklad do you think it's reasonable if
WorldState::options holds a
lsp_types::SemanticTokenTypes and modifiers? In other words do we care if it knows about lsp types directly or should I store them as strings instead?
at some point we need the server to compare its list of supported token types/modifiers with the clients and use that as the list to generate tokens and modifiers from
I would probably put that info in
I think we need
fn token_legend() -> LspLegend
and just the usual
ConvWith impl? Ie, we don't need to hold any state apparently?
Well... I think you need to loop through the server tokens and compare them with what the client supports and use that as the legend to send back from the server capabilities: https://github.com/microsoft/vscode-languageserver-node/blob/master/testbed/server/src/server.ts#L111
Hm, I would think this is advisory? Like, the server could adapt its tokens to the client ones, but it doesn't have to?
That's not how I'm reading the code but I do see in the comments that describe the encoding that "at index
tokenType: will be looked up in
SemanticTokensLegend.tokenTypes" so maybe you are right. It would certainly make it easier and I wouldn't have to deal with client caps
I'll go with that