Fallback to word highlighting when contributions don't provide document highlights

[bgashler1]

• VSCode Version: Insiders
• OS Version: Windows 10

Regarding test plan item #12100

Steps to Reproduce:

1. May not be a problem, but just filing this issue to be safe. I'm looking at an old version of VS Code site that was originally written in Razor. It's the example-word-count.cshtml file https://github.com/Microsoft/vscode-website/tree/3cfa8213681f680418997c7671fa1b8c452ac2af
2. Try clicking on the class name updateWordCount pictured below on line 79 and note that it doesn't match the symbol with a highlight like it does in Stable today as shown in the picture.

Left is Insiders. Right is Stable.

[dbaeumer]

Word highlight is broken in CSHTML. Not sure if this should be the normal word highlight or whether this is a language word highlighter.

[sandy081]

I see word highlighting is broken for HTML, CSHTML and HandleBars

Since, HTML has been extracted into a separate language server and this functionality has been lost. Moving to October.

This has to be documented as limitation in release notes

[felixfbecker]

#1751?

[aeschli]

The html extension registers a document highlighter provider. This seems to prevent the default word highlighting. The same seems to happen in TypeScript: Select a word in a comment does not highlight it. Handing over to @jrieken.

[jrieken]

It seems like that was done on purpose by @alexandrudima - see: https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/find/common/findController.ts#L814

Waiting for him to comment

[aeschli]

IMO this must be fixed. It's a regression for the HTML mode which no longer shows word highlighting for anything but tags (which are served by a document highlight symbol provider).
To not interfere makes sense for all locations where there are already results by a document highlight provider. For locations without any results, it would be nice if regular word matches show.

[jrieken]

Not really sure what you mean @aeschli. Yes, we have no more nested modes and lost smart highlight for embedded languages, the rest is driven by the word def, or by the implementation your extension provides.

[aeschli]

I verified that my word regex is now correct. As you observed in your comment above (https://github.com/Microsoft/vscode/blob/master/src/vs/editor/contrib/find/common/findController.ts#L814), word highlighting is skipped if there is a highlight provider.
IMO word highlighting should not be skipped if none of the highlight providers has any results.

[alexdima]

Yes, this must be fixed by the DocumentHighlightProvider aka the HTML extension.

The principle is very simple: if there is a semantic highlighter, do not do a stupid word highlight if the selection is collapsed. If there is a real selection, then the selection highlighter kicks in.

@aeschli The same was happening before, the html worker used to have code in place to fall back to word highlighting.

[aeschli]

@alexandrudima So I'd reimplement what the default (aka stupid) word highlighter does in the html extension. And if there's another extension that adds a smarter highlighter provider that also has some highlighting for the words I don't support, that will conflict with the 'stupid' ones the HTML extension would provide.
IMO it would be better if the default behaviour is done by VSCode:
If no provider gives any result on a given empty selection, then provide a default highlight.

[alexdima]

@aeschli Please do as you wish, as far as I'm concerned you are free to take ownership of SelectionHighlighter and WordHighlighter, and issues associated with them.

[aeschli]

It was a behaviour change, but we haven't had many complaints about it since then.
Changing to 'feature-request'

[aeschli]

Closing as there have been no complaints about the new behaviour.