Repository navigation
Consider showing completion item detail if available for all list items #39441
Description
Take the following completion list.
Each Client item belongs to a different namespace. If the completion item detail was shown immediately for each item then users could, at a glance, easily identify the relevant item out of a list of similarly labeled items. I suppose the argument against is that this can be done by modifying the label to include this, but then what is the role of the detail property?
Activity
bmewburn commentedon Feb 7, 2018
Furthermore, if an extension author does try and add detail to the label to work around this limitation, then it can end up with incorrect highlighting as shown below.
olafurpg commentedon Feb 13, 2019
Any pointers on how to contribute a fix displaying the
"detail"field if it's available? This seems like a low-hanging fruit that would greatly improve the user experience in cases like belowgabro commentedon Feb 13, 2019
As an extra data point, the Java LS works around this by including the package in the
"label":bmewburn commentedon Apr 30, 2019
Gabriele Petronella (@gabro) , when using the label do you find it can cause incorrect highlighting as in the example above, though?
olafurpg commentedon Apr 30, 2019
Ben Mewburn (@bmewburn) the highlighting works out ok in my experience if you update the filter text to not include the appended namespace.
jrieken commentedon Dec 11, 2019
fyi - I plan on implementing this for the next (Jan 2020) release and that "label + detail" workarounds will then look bad. Because of that we might start with having this behind a setting
jrieken commentedon Jan 3, 2020
This should also help with Java which often presents a very busy IntelliSense box, where too much is rendered as label. cc Rome Li (@akaroml)
propose CompletionList#isDetailsResolved, #39441
adopt isDetailsResolved for snippets, #39441
65 remaining items
jrieken commentedon Jun 21, 2021
This is how a fake sample would look today. The rendering and fading level can certainly be tweaked. If we go with
signatureand droptypewe could also make qualifier rendering different.It doesn't look good when combined with qualifier. There is some alignment and spacing issues...
jrieken commentedon Jun 21, 2021
LSP proposals are usually a clone of VS Code API proposals. Until a week ago it was still parameters in VS Code but we decided to change that and LSP apparently didn't catch-up. The question about encoding semantics isn't answered tbh - completion does use program'ish lingo in some places, like its kinds . The use of name, signature, qualifier is more for a lack of good alternatives and to provide minimal guidance. I am open for suggestions, but I believe the usual triple of label, description, and detail won't work well...
The problem is that scrolling doesn't happen in the usual linear fashion. Users "type to select" which means they are very likely to see a mix of resolved and unresolved items until they have typed "enough" to only see few, resolved items. Like, ts returns 10000 items with top100 resolved. Now, the user types and with that removes/filters say 3000 items which means from the top100 only every third item is resolved, or none, or only one... Now you have a happy mix of resolved and unresolved items and ts would be busy catching up with the typing-speed of its user.
I do agree that the ts challenge is separate from the shape of this API (cough, cough #88757) and I don't want to block other extensions any longer because of that. I am not yet convinced that lazy resolving is the answer because I don't believe the UI will feel good but I am happy to try. Indeed, I did start a prototype which operates with incomplete completion lists and resolves in batches. I just couldn't parse the detail-information into a usable format and I do acknowledge that the incomplete result approach is very complex. Maybe ts can divide this into smaller problems, like have complex labels for member completion or something else low hanging. I also don't quite understand why this is so expensive for auto-imports. The full path is already there, we make it relative to the workspace and wouldn't making it relative to the project instead be all?
On a related note: we do have requests to allow extensions to differentiate between automatic and explicit requests for completions. Users that have pressed ctrl+space are likely more willing to wait than those that use completions as you type. This has been raised explicitly for global completions (by Java) and I do believe it's an issue independent of complex labels or not. Yes, complex labels have the potential to slow down this unpredictably complex operation but they are not the root cause.
andrewbranch commentedon Jun 21, 2021
The thing I’m confused about is, this is already essentially what’s happening with
isIncomplete. I’ve added a bunch of optimizations that make our incomplete-triggered requests really fast (15–30ms), but if I add some delay in there, I can see that the completion list UI is totally static while waiting on the response. I don’t see how that’s different from what I’m suggesting, except that my suggestion can also apply to a linear scroll while not typing.rendering tweaks for complex completion labels, #39441
jrieken commentedon Jun 22, 2021
Todays thinking behind
isIncompleteis incomplete wrt the number of items returned, not wrt to the depth of items. However, it does allow for such an experiement. I also do agree that the UI lacks a "loading more" indication. This is a little tricky because often we are dealing with complete and incomplete results at the same time and we don't want to block the whole UI. By now we have an optional suggest status bar and that could show some kind of loading indication.jrieken commentedon Jun 22, 2021
On the UI and API - the current thinking is to reduce this to: label, signature, and qualifier. There needs to be a better name for "signature" because it is meant to be arguments and return type, or type annotation etc... So, maybe avoid programming lingo and use detail. Also two rendering styles: (1) all in one row (with spacing and opacity tweaks) or (2) right align the qualifier portion
DanTup commentedon Jun 22, 2021
I was just coming to suggest
detailordescription(both used elsewhere). Although it may be a little confusing there there'sdetaildirectly on theCompletionItemand now also on thename.Of the screenshots I prefer the second one - the first one makes it difficult to scan the filenames (which might be important if you're trying to pick something based on that because there are duplicate identifiers).
What will be shown in the case where the extra information popup is visible? Will any of this information disappear and/or be shown there? (given that it may be truncated here, it seems like it'd be useful to show in the other popup too, but it's not clear if VS Code would do that or we should make it part of the documentation).
jrieken commentedon Jun 22, 2021
Some thoughts over here. Tendency to go with the triple of label, detail and description
No changes for the details widgets planned. It should show items details and doc as it always does.
use label, detail, and description for CompletionItemLabel, tweak ren…
merge CompletionItemLabel into CompletionItem#label, #39441
jrieken commentedon Jun 28, 2021
This is what has been finalized. Those that can, please give it a try and report back with concerns and issues.
vscode/src/vs/vscode.d.ts
Lines 3978 to 4001 in 24f9000