Alternative fuzzy searching

[david-driscoll]

My single biggest favorite feature with Atom, that really keeps me from using vscode all that much, is atom's amazing fuzzy searching.

They have a package fuzzaldrin that does an amazing job at handling missed characters, and just getting to the result you need with ease.

Is the vscode team open to extending how fuzzy searching works, perhaps adding an option to define an alternative scoring function, as part of a users profile?

[egamma]

Thanks for the pointer. I'm very interested in 'adoption blockers' and in tuning our quick open even more. We should definitly look into this.

+@stevencl

[bpasero]

For december I actualy tweaked the quick open search algorithm to include more results. Before we would not match a file quickopen.test.ts when you searched for open because we did not search for the string inside the name.

There are more things we can do to come closer to what Sublime/Atom do:

• include the full path of a file to match on instead of just the name
• match fuzzy, that is if you search for ott it would match quickopen.test.ts because there is a sequence in the file name of these characters, even though not directly connected (I think ott could be rewritten to o*t*t* to express this)

I am happy to work on this and give it a try. I am not sure we need to make this an option as long as the most relevant results are sorted to the top.

[bpasero]

We talked about this at lunch and have an idea how we could make some progress here and get feedback:

• if you use slash or backslash in your query, we always match on the full path because that is a good indicator for wanting to match on folder names
• we introduce a new quick open provider for fuzzy searching that enables all of the features (fuzzy match, match on full path) while not changing the existing behavior of quick open. we add a keybinding for it and so you can override the normal quick open with the fuzzy one easily

[egamma]

👍

[david-driscoll]

Another place I was noticing there was an incosistency with TypeScript suggestions, where if I didn't have the proper capitalization, results would disappear.

I'm not sure if that should be a new issue or not. Most atom plugins, for example atom-typescript and omnisharp-atom, also use the same fuzzy searching so their filtering behavior is very very similar to the behavior in the rest of atom. It would be great if there was a common api/module for code as well, to keep things consistent.

[bpasero]

It is a good point that we have more places in the UI where fuzzy matching can apply and just introducing a new quick open provider for fuzzy matching file matches is not enough in that case. Given that, having a global option to enable fuzzy matching for all places (file search, goto symbol, intellisense) is probably the better option.

[bpasero]

@david-driscoll can you share an example of where intellisense did not return results when you expected them?

[david-driscoll]

That's a very good question, I just tried to see if I could replicate the behavior I was seeing, and I was not able to get it to happen anymore. To be fair I use vs code fairly irregularly, so it's possible it was fixed in the version I just updated too. I'll try again tonight from my laptop, which is where I saw the issue in the first place.

[bpasero]

@david-driscoll thanks. what I am trying to understand is if fuzzy matching should be applied to anywhere in the UI including intellisense, or selectively, starting with the picker. While I can see the value for the picker, I am not yet convinced for intellisense because I feel that I would never type a sub-string of a method to complete, I would always start with the first letters. And we do have camel case matching, so you can still type the upper case letters of a type to complete it, so we are having something very similar there.

[david-driscoll]

From a "feeling" point of view I shared many of the same principles that were ingrained from VS / R#. Then once I started dog-fooding atom building OmniSharp with omnisharp-atom I finally understood how useful it can be, it was a huge mental shift, and it's hard to shift back (not impossible mind you).

By letting fuzzy search everywhere even if you only know a few characters in the method, you can find the result with some insane speed and precision once you get used to it. There are some problems too, because when you're filtering large lists, you're expanding the result set as well, which could have performance implications as well.

I'm not saying it is for everyone, and I'm not even sure if it fits the "vision" for vscode that the team has, that's up to you guys to decide. 😄

[bpasero]

I have pushed a change to enable fuzzy searching for file matching in quick open. I decided to not touch any other UX area until we get some feedback on the sorting and matching. The new option is search.fuzzyFilePicker and disabled by default. I do think that eventually this option would go away and we just enable this by default.

I see the request for broadening fuzzy matching to other places of the UI but I am not yet convinced we should do that. I played around with fuzzy matching in the command palette and was not happy with it. The issue with fuzzy matching is that you also need to do fuzzy sorting: more relevant results to the top. However for the command palette we chose to sort entries by name to keep the result list stable and memorable. Enabling fuzzy for commands would change the sort order for each search you do making it harder to learn the list of available commands.

[mohsen1]

+1 to fuzzy matching file path, extensions and partial names. I can't find "search.fuzzyFilePicker" command though. I'm using 783ecf8

[bpasero]

@mohsen1 this will be available in our December release, the commit you are on was a bugfix release only.

[bpasero]

Closing to reflect the work that was done. Suggest to open individual issues for bugs around the implementation and requests to broaden fuzzy searching to other places.

[alexgorbatchev]

@bpasero I'm also very interested in seeing file paths to be included into the quick search. We have lots of component/index type of tiles which renders current file only matching useless. I see there was some work done and I was trying to search through the vscode base for the place where the matching is happening, but it's proving to be more difficult than I expected. Any chance you could point me to a commit or a place in the code that I could use a starting point?

[bpasero]

@alexgorbatchev the code that matches on file paths lives in https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/services/search/node/fileSearch.ts#L234

When you enable the new filePicker.alternateFileNameMatching option, paths will be searched automatically, did you try it out?

[bpasero]

We decided to make fuzzy matching the default for our next release and remove the need of setting this option.

[fxck]

Whatever fuzzy matching is VSC using, it's just bad compared to atom or ST.

When searching for menu.component.ts:

1. you can't use spaces, mncmp will match, mn cmp won't
2. you have to get the order of words right, ie. mncmp will match cmpmn won't

[bpasero]

@fxck with our upcoming release we fixed the space issue (1). Intentionally we are not finding results that have wrong order of characters, so yes there is a difference.

[lePereT]

Is Intellisense fuzzy completion planned? being able to type 'pln' to get 'println' is engrained in me from ST...

[lesbaa]

^^^ Yes please. Fuzzy code completion would be awesome.

[danielsamuels]

An example I'd love to see improved is a situation where you're typing the first characters of multiple files in a path. Here's an example where I'm trying to get to settings/base.py:

Other editors such as Sublime and PyCharm would choose the file I'm looking for, but VSCode doesn't seem to. I would recommend that the scoring system takes into account a couple of things:

• The number of sequential leading characters that match in the path.
• The percentage of characters in a path which have been matched.

I feel like taking these two things into account would drastically improve the fuzzy searching. I would like to see the fuzzy search system in general be pluggable as the OP demonstrates, that would allow for personal preferences to be taken into account much more easily.

[ackvf]

My two cents to haet the discussion. I am trying to use the Emmet: Remove Tag with >ert.

If I want to look for a word, I always use it's leading characters, for Insert Snippet it would be something between ic -> InsSnip. For me it doesn't make sense to match results from their trailing characters, such as ErtPet == Insert Snippet

It makes more sense (>ert) to either look for words starting with ert... or for distinct words using these letters as their initial characters e... r... t..., then show any other substring occurrence ...ert... and ...e...r...t....

[ackvf]

This is also annoying

[fluffynuts]

So 2c here:
mostly, the fuzzy searching is useful. But sometimes it's way too fuzzy and promotes fuzzier matches over more specific ones. So I'd really like it if there was a prefix or something one could use to search "more specifically". Thoughts?

[maxshelley]

I was wondering if there is any update to this? I did look around before posting here, but couldn't see anything. Apologies if there's a better place for this.

Coming from Sublime, I find myself typing what I think is quite file-specific paths but the ordering throws me off. Here's an example:

I want new.html.erb (the 5th result), but the top result contains only a few of the characters. Is there code or a setting where I can adjust this?

[PaddyMann]

Ditto - the file I'm after is regularly listed last, with crazy matches coming up first (like with the screenshot by danielsamuels).

Any chance we can reopen?

[fluffynuts]

"crazy matches" doesn't even come close to describing my experience with this finder. Often, I specify the folder and file name (eg "moo-cow\element.ts") and the file I want might be in the list, but with the most relevant data out of view (because the path is long) and it's not at the top -- it's often somewhere in the middle, whilst letters out of the path I've provided are singly matched to letters within other paths. There really needs to be some ranking algorithm applied to the match results such that matches for the full string, in order, that I've typed in are right at the top.

[PaddyMann]

I've raised a new issue: #35572