(feat) Semantic document highlight

[jasonlyu123]

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:

1. 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.

2. 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.

3. 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?

[igorlfs]

Hey, is there any chance of this getting merged? It'd be nice to have when using other clients

[jasonlyu123]

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.

[jasonlyu123]

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.