Enable fuzzy matching for picker

[ramya-rao-a]

Have a quick pick control with these values ["hello", "hello_there"]

Type ht or hello_ -> hello_there will show up Type he_ -> no results

[bpasero]

@ramya-rao-a I looked into this and this is because true fuzzy matching is not enabled for the picker. The difference to our current matching strategy is that true fuzzy matching allows to return a result as matching if the search characters are part of the target word even if there are other characters in between. The fact that ht matches is due to our camel case matching.

I think it would be tough to enable this for all pickers so we might need an option here for the extension to enable this.

[szyhf]

Nice ~

[fabiospampinato]

@bpasero why are there even different algorithms being used? This is surprising to me.

We surely can't expect users to think "is fuzzy search enabled in this picker? maybe I should search for bar instead of br here". If there was an option for extensions to enable fuzzy search this kind of reasoning would become even messier.

I think it would be tough to enable this for all pickers

Why is that?

[bpasero]

@fabiospampinato the fuzzy scoring we do currently was tweaked for file names only, it is not a general purpose fuzzy scorer. That is why it was not enabled for all contexts. I think before we can do that we should revisit our current implementation and think about dropping in a better one that is just generally matching better.

[fabiospampinato]

@bpasero I think the "filtering" and "ranking" logic should be considered separately. It would be pretty easy to enable fuzzy filtering everywhere (ranking results naively on the order of appearance) while still having a custom ranking logic for file paths.

[Eskibear]

@bpasero I cannot figure out why here 1 matchs but 2 not ?

More details here: https://github.com/Microsoft/vscode-spring-initializr/issues/26#issuecomment-359306866

Version 1.19.1
Commit 0759f77bb8d86658bc935a10a64f6182c5a1eeba
Date 2017-12-19T09:46:02.926Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture ia32

[bpasero]

@Eskibear we have a heuristic when we should try to match on camel casing (by jumping over words), but this heuristic is limited to entries < 60 characters length for performance reasons. The second label simply seems too long for that kind of matching to apply.

[smbkr]

I think it would be tough to enable this for all pickers so we might need an option here for the extension to enable this.

@bpasero it's been more than a couple of years since this was looked at. Has anything changed in the current state of VSCode that would make it easier to implement fuzzy search everywhere? This limitation has come up a number of times in extensions as can be seen from the mentions.

[xh3b4sd]

I created https://github.com/alefragnani/vscode-project-manager/issues/428 and was directed to here. It looks like there are quite a couple of supporting arguments to improve the current state of searching. Though what I am not sure about is why the behaviour in search is different when searching for different things.

[gpeal]

I recently switched from the IntelliJ world to VSCode and the fuzzy match algorithm of VSCode is slowly driving me insane. In addition to the cases here, one thing that IntelliJ gets really right is case sensitive matching of partial words and priority for local symbols.

Check out this example. I am trying to match externalReport which is defined on the line immediately above. ext correctly matches. Typing R should increase the weight of the already-top result but instead, it drops off the list entirely.

The result of this is that I frequently wind up with random variables and imports as a result of the correct result disappearing after I type more letters that should only increase its weight.

You can see a similar result play out here: vs WebStorm:

[gpeal]

Here's another example. I think it is reasonable to expect InteractiveTableComponent to be matched above footprintTaggingBuilderAddRuleComponent, right?