Completion sorts different depending on whether it was filtered client-side or invoked after typing a prefix

[DanTup]

• VS Code Version: 1.55.2
• OS Version: macOS Big Sur 11.2.3

Steps to Reproduce:

1. Create a completion provider that returns the following:

 [
    CompletionItem(label: 'Foo.one', sortText: 'aaa'),
    CompletionItem(label: 'OSError.noErrorCode', sortText: 'zzz'),
  ]

2. Invoke completion and type on and note the ordering of the results
3. Re-invoke completion with on already typed

Results if invoking completion and then typing "on":

Results if invoking with "on" already typed:

This may be by design, but it doesn't seem consistent with the description of sortText:

vscode/src/vs/vscode.d.ts

Lines 4052 to 4055 in 08f9bbc

	* Note that `sortText` is only used for the initial ordering of completion
	* items. When having a leading word (prefix) ordering is based on how
	* well completions match that prefix and the initial ordering is only used
	* when completions match equally well. The prefix is defined by the

I suspect it could also behave strangely with isIncomplete=true as that can fetch new lists from the server after keypresses. If the server-provided ranking will be used even with a prefix if the client has done no filtering, I think that should be documented.

[jrieken]

Please enable explain mode via Cmd+/ to see the ranking for each item

[DanTup]

Ah, I wondered how to enable that - I'd searched the command palette and not found it!

Here's after I typed "on" and it was filtered client-side:

And here's when I re-invoke the completion manually after "on" has already been typed (note: screenshots are in the displayed order, so the first one here is the second one above):

Strangely they seem to show the same score, but the order is different (if they should fall back to the sortText in that case, it seems like they'd be consistent - although whether it's correct they both get the same score I'm unsure).

[jrieken]

Strangely they seem to show the same score, but the order is different (if they should fall back to the sortText in that case, it seems like they'd be consistent

When you typed the o the score for OSError... was stronger than for for Foo.one and therefore the item got sorted atop. Since sorting is stable it doesn't restore the order after score equalize.

[DanTup]

@jrieken but if the scores are equal, shouldn't it be sorting by sortText? The text above says "the initial ordering is only used when completions match equally well" which seems to match here?

If it's deemed this is working as intended, can you confirm what the intended behaviour is when using isIncomplete=true? If VS Code triggers a new request and filters client side while it's pending, then the request completes with the same results that VS Code had filtered to, would it retain VS Code's sorting, or would it overwrite them with the servers?

If the latter, it seems like inIncomplete=true may allow us to override VS Code's sorting (which would make me happy, although I expect is not intended).

[jrieken]

the initial ordering is only used when completions match equally well

The initial ordering is after the results are retrieved and before scoring against a prefix.