syntax: Highlight block label as "enumMember" & highlight unquoted labels #943
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
HLC considers the quotes to be effectively part of the same token (label), i.e. it treats both quoted or unqouted labels the same, although quoted labels are considered best practice. We reflect the equivalence here and assume that quotes (if present) will be highlighted the same as the string between the quotes.
The two character classes are (AFAIK) equivalent and this just ensures we use one style throughout the grammar.
In LS we assign "enummember" token type to block labels which paints them blue in the default VSCode themes. To provide better UX without flipping colours we aim to match what LS does with 'variable.other.enummember' Sadly themes do not support entity.name.enummember which would make more sense semantically.
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is to complement hashicorp/terraform-ls#802 by aligning the scope of block labels in the grammar with semantic token type assigned by the language server.
It may seem counter-intuitive or wrong from semantic perspective to use
variable.other.alongsideentity.name.(used for known block type) for labels but as explained in the commit log - this is mostly a pragmatic decision made to provide better UX which otherwise would be hard/impossible to achieve due to the scopes used by default VSCode themes.As mentioned in #802 we explored a number of other token types which VSCode mostly ends up just mapping down to available scope names per https://github.com/microsoft/vscode/blob/de9ab35ce9da7cb3c850a1b570876263a472174b/src/vs/platform/theme/common/tokenClassificationRegistry.ts#L540-L570
So these are the limitations we have to work within. Our future hope is possibly addition of some more token types into LSP as described in microsoft/language-server-protocol#1067
Before
After
Future Enhancements
@dbanck rightly pointed out that the LS/extension alignment may do a dis-service to the user in case of "invalid" labels. This is tracked under hashicorp/terraform-ls#804
There was also point made in #710 about distinguishing "dependent labels" from "freeform-text labels". This is tracked under hashicorp/terraform-ls#803