Support custom modifiers via BlockSchema & LabelSchema
#106
Conversation
This aligns with conclusions from microsoft/language-server-protocol#1415
This enables downstream schemas to declare their own modifiers, e.g. "terraform-resource".
92d6e21 to
35625f5
Compare
35625f5 to
7073d32
Compare
This makes it possible to use the types directly downstream without having to convert them into strings.
Potentially yes, although I imagine traversals would be wanted more. I wanted to ship at least basic support for this though. We can always add more later, removing is typically harder once people rely on it and I'm not entirely sure what the best modifiers would be in the context of traversals and attributes yet. We already set dependent modifier for some attributes, like Similarly for traversals folks may want to highlight the whole address (e.g. So ... TL;DR lots of questions to answer still IMO. |
|
Thanks for the explanation and for raising more questions 😄 |
The LSP spec is not explicit in saying that custom token types or modifiers are supported, but it does neither explicitly say it's forbidden.
The fact that the underlying type for both is a
stringand that there is relatively detailed corresponding client/server capability available suggests this is possible.The expectation is that downstream LS (
terraform-ls) would use the client capability to see what token modifiers the client actually supports before offering them any custom ones and it would continue providing fallback, just like terraform-ls does today:https://github.com/hashicorp/terraform-ls/blob/2de83c81f9e53457b943efaf0801acf6185b71b3/internal/lsp/token_encoder.go#L37-L86
The benefit is that clients which do support more specific token types and modifiers can use those - which in turn enables more specific themes that can take advantage of these. Clients which do not support these will continue to use the fallback types & modifiers. So basically - everyone's happy? 😄 🤞🏻
Related: hashicorp/vscode-terraform#958