-
-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(feat) Semantic document highlight #1408
base: master
Are you sure you want to change the base?
Conversation
…nto semantic-doc-highlight
…nto semantic-doc-highlight
…nto semantic-doc-highlight
function and class highlght its name
Hey, is there any chance of this getting merged? It'd be nice to have when using other clients |
The main reason for the inactive is that this is not reliable. It won't work when there is a syntax error in the template. But maybe it's still better than nothing. We could probably mark it as experimental and off by default. |
…nto semantic-doc-highlight
It's now marked as experimental and off by default. We could make it on by default if people don't care much about the parser error problem. Similar to the folding range. I also added a word-based solution for unsupported embedded languages. The svelte result is also calculated using the AST returned by svelte2tsx. Unlike the folding range, there isn't a word-based fallback when there is a parser error because the result is too different. |
…nto semantic-doc-highlight
…nto semantic-doc-highlight
@dummdidumm What do you think about this? Do you think it makes sense to mark it as "experimental" or just off by default should be fine? Or maybe you think it can be enabled by default. The "unreliable" is similar to hover so maybe it's acceptable? I am just not sure if people would think the "unreliable" is worse than the default word highlight. |
This adds support for document highlight. Making the document highlight be based on semantic/syntactic meaning instead of the current word-based default by VSCode. This also makes the document highlight available for other LSP client since a lot of them doesn't have a word-based fallback and it does look kind of weird without it.
As usual, the result is provided by
vscode-css-languageservice
,vscode-html-languageservice
and typescript. As for the svelte plugin, I highlight the svelte block and tags. For example, if block highlights#if
,:else if
,:else
and/if
.The downside of the current approach is that ts, svelte document highlight in the markup won't work if there's a syntax error in the markup. Also, for unsupported embed language users, like pug, sass, postcss and stylus. It might be a worse experience. With that said I think it would still be a good addition.
To discuss:
Do we think this is better than the word-based in vscode? If not maybe we could make it disablable and disable this by default in vscode. But enable it in the server by default. For it to work, we have to set the server capability based on config.
To address the worse experience for unsupported embed language. I am thinking if we can implement a word-based by ourselves and return the word-based result for these languages.
The svelte compile result may not be reliable enough. So maybe we can blank the style and script tag like in svelte2tsx and use that instead. Or maybe even move to the typescript plugin and use the AST returned by
svelte2tsx
instead?