Investigate eagerly returning more information about suggestions
See original GitHub issueProblem
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
:
![Screen Shot 2020-01-17 at 11 26 30 AM](https://user-images.githubusercontent.com/12821956/72640392-a34fb980-391c-11ea-9d49-bbd13917e5bc.png)
This design also reflects the design of the suggestion api:
completionInfo
returns the entire list of suggestions, but only includes the namecompletionEntryDetails
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
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:24 (22 by maintainers)
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
:(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)
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.