Discussion: Syntax highlighting for CompletionEntryDetails displayParts

[mjbvz]

Problem
With microsoft/vscode#34188, we are looking to add syntax highlighting to the detail section of VS Code's documentation. Currently we use the displayParts field on the CompletionEntryDetails response for this. However the returned display parts are not always valid TS/JS code blocks, resulting in incorrect colorization in some cases:

In this example, const should be blue. The unclosed interface causes it to be colored incorrectly.

TypeScript currently returns basic token info using the SymbolDisplayPart type, however we cannot use this in a VS Code extension for colorization

Proposal
In the Date example, there are really two blocks of code:

interface Date

and

const Date: DateConstructor

The first block is the primary label for the item while the other block provides additional info. Other completion items may have more than two sections.

I propose adding a new additionalDetails field to CompletionEntryDetails as follows:

interface CompletionEntryDetails {
    ...
    displayParts: SymbolDisplayPart[];
    additionalDisplayParts?: SymbolDisplayPart[][];
}

• displayParts would contain the primary label for the item, such as interface Date. I imagine this should always match what we return for quick info on the symbol
• additionalDisplayParts would be an optional set of additional code blocks to display, such as const Date: DateConstructor. Each code block would be syntax highlighted on its own

This change would be mostly backwards compatible, however older clients that do not support additionalDisplayParts could lose some display information

Any other thoughts on how we could implement this?

[mhegazy]

@sheetalkamat any thoughts on how we can make this simpler for VSCode?

[sheetalkamat]

@mjbvz Wont you be directly be able to map SymbolDisplayPartKind to tm scope instead of using extension to get the scopes?

[sheetalkamat]

@mjbvz do we still need this?

[mjbvz]

We still don't have a good story for this on the VS Code side so I'll close this. We may revisit this sometime in the future since it would be nice to have, but we need to figure out how we want to support it in VS Code