Fuzzy finding

[ljnsn]

Hi, thanks a lot for this plugin, I enjoy using it.

One issue I have is that it doesn't seem to "fuzzy search", only "fuzzy match". One of the things I like most about "oldschool" telescope file search is that I can just type what I'm looking for with spaces and don't have to care about every single part of the path.

For example, let's say I have a directory like

- A
- |-AB
- --|-ABC
- -----| file_x
- -----| file_y
- --|-ABD

If I'm looking for file_y, but I don't know what the file is called, but I know the path, I'd search for "AB ABC" for example and I'd get all files under that directory. With this plugin, I have to search "AB/ABC". The classic way also works for more deeply nested structures so I could also search for "A ABC" for example, so I don't need to remember the name of the intermediate directory. With this plugin this doesn't seem to be possible at all.

Would it be possible to integrate this or is it maybe already possible and I need to configure it somehow?

[danielfalk]

This could depend on the match algorithm you use. For fzf, if you want your search to completely narrow down the results to a particular subpath, then you'd probably need the search to be AB/ABC because separating by spaces seems to search as if those are independent terms.

The point of this plugin more broadly is not to come up with the ultimate matching algorithm. In fact the algorithm is supposed to be a little less important because smart-open will also consider other factors when presenting the search results. Using these other "clues" about what you're searching for should mean that you have to type less to get to the file you want.

So I'm not exactly optimizing for the case where you have a full path in your mind and you know just the right search pattern that will filter out all others. For me, that's usually too much thought and too much typing. Rather the idea is to type a few characters and in most cases the file I want is in the top few because the relevance sort is doing the heavy lifting.

[ljnsn]

Thanks for the explanation, I'm not sure that's accurate though, because I'm using the same search algorithm in both cases (fzf). So shouldn't the behaviour be the same then?

Rather the idea is to type a few characters and in most cases the file I want is in the top few because the relevance sort is doing the heavy lifting

I feel like this works well in smaller code based, but becomes impossible in larger ones. Out of curiosity, let's say you have several files called foo, in different subdirectories model, endpoints, data, etc. how would you search for a specific one of them?

[danielfalk]

Thanks for the explanation, I'm not sure that's accurate though, because I'm using the same search algorithm in both cases (fzf). So shouldn't the behaviour be the same then?

Smart-open takes several factors into account as explained in the readme, so that might explain any discrepancy. I can't think of any other explanation because this plugin doesn't alter the search terms and doesn't do any processing for the full-path search.

I feel like this works well in smaller code based, but becomes impossible in larger ones. Out of curiosity, let's say you have several files called foo, in different subdirectories model, endpoints, data, etc. how would you search for a specific one of them?

Looking for foo in model, you can search for model/foo. You can search for modfoo even. mod foo would also get you there. In some cases, sure, there are instances where you might have to narrow down a specific file by having a full path in mind. I don't optimize for that case alone though.

I'm not sure what you'd mean by a large codebase. The codebases I most work with have about 3-4 thousand files apiece, and this seems to work well for that. Then again, I know there are some people who work in repositories that are many times larger, and might have a particular file structure that presents a certain challenge (like most files having the same name or something).

Also, while I'm not optimizing for a full-path matching sort of behavior specifically, the more you use it like that, the more it will behave that way. In other words, if you search in such a way that your search would match the full path, then when you select the file you were looking for, the database gets updated in such a way that future searches will yield results that match the full path, and other factors won't play as much of a part. This happens gradually as weights are adjusted.

[danielfalk]

Here is reproduction using your example file structure above:

Here's my search

You can see that the files under ABD are eliminated. This is using the fzf algorithm. So it works, but with the fzf algorithm, A ABC is just treated as 2 separate terms, so it doesn't necessarily eliminate the same entries that A/ABC would. So I'm guessing that while it seems like you're getting different results from plain fzf, you're likely just getting a different ordering, based on the other factors?

[ljnsn]

Thanks again for taking the time to write an extensive answer! I think there must be something wrong with my settings in that case, because as soon as I type a space in the search, it just doesn't match anything anymore, which is in fact my main issue. It's like it tries to match a space and there is obviously no space in any of the filenames or directories. Other than that it works flawlessly and indeed mostly puts the correct file on top using the shortest possible search term.

[danielfalk]

No problem. Yeah the behavior you're describing sounds a lot like the fzy algorithm.

[ljnsn]

@danielfalk just to let you know, I was indeed using fzy, because the telescope extension config for the plugin was misaligned inside another extension's settings and thus didn't take effect...

Thanks again for the help and the plugin!