Open brunnerh opened 4 years ago
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:
@brunnerh if we could disable matchOnLabel
(see #83425) (as well asmatchOnDescription
and matchOnDetail
which we already have you could just disable matching and implement the filtering yourself before you put the QuickPickItem
s into the QuickPick
. Coupled with custom highlighting (#83424) you would be able to do whatever you like.
I agree with @brunnerh, about disable match at all, so we could handle the filter ourseves
Setting alwaysShow: true
on the items and sortByLabel: false
(#73904 proposed API) on the QuickPick allows you to control the list and sorting. Only the highlighting cannot be controlled yet, that is tracked with #83424.
Keeping this issue open as its own proposal until the issues are resolved.
@chrmarti the alwaysShow: true
does nos seems to work this way. I have tried to use, but it still keep hiding results based on it owns filter algorithm.
Because of this, i have to do an workaround here: https://github.com/tatosjb/vscode-fuzzy-search/blob/master/src/search.ts#L66
${this.searchString} - ${path.parse(filePath).dir.replace(workspacePath || '', '')}
the ${this.searchString} -
on the start of the expression is necessary because of that.
Another option, simpler but less flexible, would be to add another prop, like filterDetail: string
and matchOnFilterDetail
, which would work the same as matchOnDetail
but just not be visible, but could play along with the other options.
The rationale here, is that I often don't want to overload the quickpick item with visual noise just to match against.
Although if something more custom was implemented, I would love it if it was a post-process on top of the existing matching (if enabled -- and it would be great to be able to opt-out of label matching), so that way if something matched because of the existing behavior the item would still be there (unless removed as part of this callback) and highlighting would still be intact on those items.
Currently the
QuickPick
filter logic supports wild cards and which parts of the item to search in but not things like switched up word order or regex. An issue was opened for one of my extensions asking for a more lenient search, which does not seem possible with the current API.Rather than adding a lot of options specifying exactly how the filtering behaves it might be easier and more sensible to provide a custom filter callback and maybe a filter delay option. The delay would trigger the filter logic only
n
milliseconds after the user has last typed, in case the filter logic is complex or there are many items (- i have 33k -) causing long filter times.Suggested interface for the options:
I had a look at handling a quick pick "manually" by using
createQuickPick
but it also filters completely automatically.Maybe
QuickPickOptions
could also be made generic. It already has theonDidSelectItem
property which uses a union for the item type instead of a generic. Then functions likeshowQuickPick<T extends QuickPickItem>
could propagate their generic type to the options argument.