vscode: Have `createQuickPick` no longer sort by label

We could add matchOnLabel (like we internally already did) to the API and couple that with filtering, highlighting and sorting. (Currently the sorting is only done based on the label.) That would fit nicely with the existing API while not exposing too fine-grained options that are hard to use.

I’d just like to add that for those using TypeScript, you can access QuickPick’s new sortByLabel flag like so: (Since it’s not in the type definitions yet.)

let quickPick = vscode.window.createQuickPick();
(quickPick as any).sortByLabel = false;

@chrmarti apologies on late reply, I never got a notification message on this thread.

Here’s some brief details to expand on the use case I outlined in the issue opener:

• QuickPick is being used to display search results
• The ‘label’ field contains the line of text which matches the search
• The details field contains the path/line number that contains that line
• My preferred sorting is by (path, line) so results from the same file are grouped together in ascending line order
• The issue is today VS Code re-sorts the list by looking at ‘label’ first and discards the existing ordering

I agree that we should at least consider these things together even if we don’t implement everything now. It’s all about who controls the presentation of items in the quick pick. Also for example, if an extension has filtered and sorted based on its own algorithm, and vscode adds highlights based on a different algorithm, that might not make sense, so I could imagine a reason in the future to let extensions return highlight ranges too. But I’m guessing the filtering and sorting that you will do will be close enough to how our fuzzy matching logic works that you still want ours to apply.

When you want to control sorting yourself, you probably also want to control filtering. I don’t want to introduce a flag specific to sorting now only to discover that doesn’t solve the entire issue.

Right, yeah it’s a change we’d like to make to get a read on how many extensions depend on the existing behavior. Our suspicion is that this existing behavior is hurting extensions more than it helps and thus the behavior of the API should change.

Naturally, this is not an actual API breakage, since no API shape is changing… it’s a behavior difference.

There is a chance that such a change would cause issues… if so, we’ll re-evaluate.

This iteration, we are planning on removing the sort logic for the bigger createQuickPick API. That would mean no API would be needed, and if you want the existing sort behavior, you can just call .sort. I’ll rename the issue accordingly.

@TylerLeonhardt can this quickPickSortByLabel proposed API get finalized soon? I recently used it in #199473 in the Git extension, which is built-in so doesn’t have any problem using proposed APIs. But we extension developers can’t use proposed APIs if we want to publish on Marketplace.

ok since it sounds like we still can’t skip sorting when the field has input, I’ll reopen this issue.

However @TylerLeonhardt please note https://github.com/microsoft/vscode/issues/54400 is probably more specific to this case so maybe we should close this and reopen that instead.

@chrmarti another option you could consider that would suit my requirements is adding an optional sortText field to the quick pick items, which has precedent in the completion items API:

https://github.com/microsoft/vscode/blob/fe1258b594c72c1ee014b66ee3193acf67d03f1d/src/vs/vscode.d.ts#L3329-L3334

I don’t want to add API without understanding the long-term direction and the highlighting, filtering and sorting all play into this.

The QuickPickOptions already have matchOnDescription and matchOnDetail flags and these control filtering and highlighting.