Content mapper: allowing document highlight result from other language-servers #64368

🔍 Search Terms

Content mapper
document highlight

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

The document-highlight result is currently an empty array when there is no result. This prevents VS Code from loading it from another language server. This is because VS Code will use the first "not nullish" document highlight result.

Would it be ok to change it to return null instead when the document is from content-mapper? In ts/js files, the next document highlight provider would be the VS Code built-in word highlighter. So ts/js files won't need to return null for the fallback. Some content-mapper files might also not need the fallback, so it might make sense to make it configurable.

📃 Motivating Example

The motivation is to allow other language servers to provide document highlights without client-side middleware. For HTML-like files, other language servers might want to provide document-highlight results for the CSS inside style tags.

<style>
.a { display: none; }
</style>

For Svelte, we also highlight control-flow blocks. For example:

{#if a}
{:else}
{/if}

We want to highlight #if, :else and /if when the user clicks one of them, like how TypeScript highlights an if block in TypeScript code.

💻 Use Cases

1. What do you want to use this for?
   Allow other language servers to provide document highlights without client-side middleware

2. What shortcomings exist with current approaches?
   No current approach.

3. What workarounds are you using in the meantime?
   No workarounds until we have client-side middleware. This can also be achieved with client-side middleware. But we also don't know how many other editors would add client-side middleware. Solving it without middleware might also help other editors that have a similar nullish check.