Investigate eagerly returning more information about suggestions

Problem

Suggestions VS Code have three broad UX parts:

• Name/label. Primary identifier for a suggestion, such as foo.
• Details. Type information or auto import info, such as string.
• Documentation. Js doc info and additional details about the suggestion item

Currently VS Code only shows the details of the currently active suggestion. This can be problematic in cases like auto imports, where multiple symbols may all have the same name:

This design also reflects the design of the suggestion api:

• completionInfo returns the entire list of suggestions, but only includes the name
• completionEntryDetails returns the details and documentation for an individual suggestion

Investigation

With https://github.com/microsoft/vscode/issues/39441, VS Code is exploring letting languages/extensions return the details part of the suggestion eagerly. This would let VS Code show details for the entire list of suggestions instead of just for the active one. In the auto import case specifically, this would likely mean showing the file paths we would import from.

We would like the typescript team’s feedback on these idea and our current proposals:

• What information would be most helpful to render in the main suggestion list?
• How much overhead would returning this information add? Both in terms of message size and TS server computation time?

/cc @jrieken For VS Code apis /cc @amcasey @minestarks for VS

[mjbvz]

I’ve measuring the perf impact of the most simple approach possible: call completionEntryDetails with the entire list of completion items (this is one TS server request but returns data for many items)

In a empty project, this call takes ~3seconds for 1500 or so completion items. So clearly not a good solution!

Just a breakdown of simples of timings for completionEntryDetails:

• 1 item - 5ms
• 10 items - 25ms
• 50 items - 110 ms
• 100 items - 200ms
• 200 items - 350ms
• 500 items - 900ms

(Note that completionEntryDetails also returns JS Doc documentation and some additional data that our completion label proposal does not call for. What I was measuring here is very worst possible case)

---

@andrewbranch At the TS/Editor sync today, we though you may the person to investigate this on the TS side. Using the existing TS Server apis, would you be able to look into:

• What easily accessibly data does TS currently have for the completions call that it does not send back to VS Code (such as the auto import source)

• What would be the perf impact of sending back this data?

• What would be the perf impact of returning all the information from the VS Code proposal (https://github.com/microsoft/vscode/issues/39441#issuecomment-575197886) except the signature

• And what would be the perf impact of returning the signature as well (we expect this to be the most expensive part to generate properly)

[andrewbranch]

In my experiment I have called completionEntryDetails once, with CompletionDetailsRequestArgs that list all items that I have just received.

Interesting. I didn’t realize that the protocol accepted an array of items, because the language service does not—in the server code we just map over this list and do the full languageService.getCompletionEntryDetails() call for each.