You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our language client is using the vscode-languageserver-client as client library. We want to customize token modifiers and token types but those capabilities are being hardcoded today in the client library.
The client should initialize the request to the server and tell the server the client capabilities.
The server will reply with the server capabilities.
Afterwards, the server will generating content that the client understand.
Meaning, if the client does not understand a new token modifier or token type, the server will simply drop that content to avoid any confusion. Our language server is following this pattern. If we want to introduce a new token type or token modifiers, the client need to be capable of this so is the server. Otherwise, the server will just drop any content related to this new token type or token modifiers.
However, here are the code analysis from the library.
In client.ts, the initialize method handles the InitialParam protocol. This is the place where the client is talking to the server about it's capabilities.
The capabilities is being filled in in client.ts. The language client is filling in the client capabilities with all the feature's fillClientCapabilities method.
In semanticTokens.ts, method fillClientCapabilities is writing these capabilities to the ClientCapabilities struct without any options to customize. Unfortunately, the semantic token feature fill in the capabilities using the hard-coded list.
Am I understanding this correctly? Is it possible to introduce an option to customize the token types and token modifiers?
Thank you.
Additional context: This is also mentioned in issue
Today, we can implement a workaround in our language server where the server will just ignore the client capabilities and always report the new token or new modifiers unconditionally. However, this does not follow the best practices of LSP capabilities I think.
The client library is VS Code specific hence it only supports the token types and modifiers VS Code supports. Allowing you to customize those will not work since VS Code itself will not support them. If you need to use a LSP server outside VS Code you should use the npm module vscode-languageserver-protocol which doesn't make any assumption about the VS Code client. It allows you to fully customize all client and server capabilities.
Our language client is using the vscode-languageserver-client as client library. We want to customize token modifiers and token types but those capabilities are being hardcoded today in the client library.
My understanding of reading LSP is:
Meaning, if the client does not understand a new token modifier or token type, the server will simply drop that content to avoid any confusion. Our language server is following this pattern. If we want to introduce a new token type or token modifiers, the client need to be capable of this so is the server. Otherwise, the server will just drop any content related to this new token type or token modifiers.
However, here are the code analysis from the library.
In client.ts, the initialize method handles the InitialParam protocol. This is the place where the client is talking to the server about it's capabilities.
The capabilities is being filled in in client.ts. The language client is filling in the client capabilities with all the feature's
fillClientCapabilities
method.In semanticTokens.ts, method
fillClientCapabilities
is writing these capabilities to theClientCapabilities
struct without any options to customize. Unfortunately, the semantic token feature fill in the capabilities using the hard-coded list.Am I understanding this correctly? Is it possible to introduce an option to customize the token types and token modifiers?
Thank you.
Additional context: This is also mentioned in issue
Today, we can implement a workaround in our language server where the server will just ignore the client capabilities and always report the new token or new modifiers unconditionally. However, this does not follow the best practices of LSP capabilities I think.
cc @hyangah
The text was updated successfully, but these errors were encountered: