Have `createQuickPick` no longer sort by label

[pelmers]

Similar to #63050, I wish to avoid the final sort on the quick pick list. I am using the quickpick as a search field, and the items field I set is already sorted by my relevance metric, so I do not want to have VS Code sort the list again . Specifically, I want an option to skip this block:

vscode/src/vs/workbench/browser/parts/quickinput/quickInputList.ts

Lines 518 to 523 in a69d0f8

	if (query) {
	const normalizedSearchValue = query.toLowerCase();
	shownElements.sort((a, b) => {
	return compareEntries(a, b, normalizedSearchValue);
	});
	}

)

[pelmers]

I would like to implement this by adding a property sortByValue to QuickPickOptions on the extension API (true by default) to control this sorting. Does that sound reasonable and would you review such a PR? Christof Marti (@chrmarti)

[chrmarti]

I wonder if that would be sufficient. What about the highlighting of the search term on the labels? Would you want to turn that off too?

[pelmers]

Christof Marti (@chrmarti) highlighting the search term's not in the scope of this issue. Could you explain why you brought it up?

I am concerned the sorting case in particular because this sort() call happens in the renderer itself. Since the extension API expects a list of items rather than a set or map, it seems logical to me to let the extension to decide that this list is already sorted and let the renderer save some processing time (especially for large lists).

[chrmarti]

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.

[pelmers]

Thanks for responding! I also noticed that filter/highlight can only be toggled for the description and detail fields, not the label field.

I imagine there was some kind of discussion when the API was originally added about its long-term vision; unfortunately that was before 'Hello Code' so it isn't in public history.

Allowing the extension to decide whether to sort results will let it provide a better experience to the user any time the default metric of 'index of first match' is not the best one.

For another example, an extension might want to keep the list grouped by category, similar to how built-in file search quickpick groups Recently opened, Search results, and Document symbols in that order.

[chrmarti]

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.

[sergei-dyshel]

After reading the discussion I still fail to understand how we went from optional sorting feature request to discussing filtering options which are not dependent on sorting in any way....

[chrmarti]

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.