Oni: QuickOpen does not prioritize matches accordingly

[badosu]

In this example I have:

• src/store/index.js
• src/router/index.js

If I type storeindex this is what I get:

I would expect index on store to be more important than a file that does not have store in the path.

[CrossR]

Have you tried with "editor.quickOpen.filterStrategy" set to "regex"? It would fix that specific issue, since storeindex would only match on the second one.

Though it may be too strong for what you want generally, such that we might just want an optional sort applying to the standard "fuse" as well if possible.

[badosu]

@CrossR Does the regex strategy work as a fuzzy-finder?

I am using it right now, let's see if this solves my long standing issues with the quick open functionality.

[CrossR]

I've found it quite nice, I'm fairly used to just typing a bit of the name of the folder I want, and then the file I want. If I'm less sure and just type the name of the file, it seems to work well still.

[badosu]

Seems like it's working out, I wonder why this is not the default strategy.

[bryphe]

Awesome! I was hoping the regex strategy would be more intuitive / address some of the issues you had, @badosu

Seems like it's working out, I wonder why this is not the default strategy.

I was actually considering switching this to be the default (i'm using it as well). If both you and @CrossR are using it and it's working out, might be worth swapping the default for next release (and seeing if anyone misses the old behavior 😄 )

[hoschi]

Hm with regex strategy the dir delimiter / doesn't work. Probably not escaped?

E.g. when opening general files which exist in more than one dir like src/features/tasks/index.stories.js I can't type tasks/in anymore.

Also with regex some matches are very weird. Why does it highlight xxxRCxxxEAT... when my search starts with act?

[bryphe]

Hm with regex strategy the dir delimiter / doesn't work. Probably not escaped?

Good catch, ya, I think it isn't escaped. We should fix this.

Also with regex some matches are very weird. Why does it highlight xxxRCxxxEAT... when my search starts with act?

I think this is a bug with the highlighter - it is just highlighting characters in the string as they show up, regardless of the order. Should be fixed too

[badosu]

I think this is a bug with the highlighter - it is just highlighting characters in the string as they show up, regardless of the order. Should be fixed too

I noticed this behaviour on the previous strategy too, so maybe not particular to the regex one.

@bryphe I think using regex as the default strategy is sensible, it works as I expected having used many other similar tools in the past. If not used as default at least we should talk about this configuration with more emphasys on the wiki.

Then I think we can close this issue.

[hoschi]

I tried current default strategy and regex since Monday, because of another bug which forces me to use Oni instead of CtrlP and I have to say the matches are not near the quality of what I'm used to from CtrlP or FZF (terminal).

[hoschi]

Some examples:

top left: FZF
top right: CtrlP
bottom: Oni (default strategy)

Oni regex:

FZF,CtrlP,Oni (default)

regex:

FZF,CtrlP,Oni (default)

regex:

You can test it on your own here, I checked in the jsconfig.json files https://github.com/hoschi/yode/tree/develop/

[CrossR]

Just out of curiosity, I tried @hoschi tests in VS Code as well, since we are using the ripgrep binary they use as far as I know. The searches all return the same results as FZF in his tests, or at least a lot closer. Only exception is the final one, where it is the same as CtrlP, since FZF is including node_modules which VSCode seems to ignore.

[badosu]

@hoschi I agree that the regex is still non-optimal, perhaps we could add an issue to make QuickOpen a more reliable fuzzy-finder.

But compared to before using the regex strategy the difference is abismal, it was pretty much unusable for me.

So I think we should use this issue to track changing the default to regex or make emphasis for it on the README and track the improvement of the strategy on another issue, with more detailed accounts on what is the expected behaviour (as you've done on the previous comments).

This suggestion is based on the assumption that this maybe not a trivial amount of work to do, however if we are able to replicate VSCode's ripgrep strategy as the default one soon then that's amazing!!

[CrossR]

I've had a look into this in other editors, and I think there is a few things we can potentially do, put I'm not fully sure of their cost.

By the looks of VSCode they use a big scoring algorithm to apply scores to the results, then that is used for the sorting : https://github.com/Microsoft/vscode/blob/master/src/vs/base/parts/quickopen/common/quickOpenScorer.ts
Looks to basically just give higher scores depending on if certain criteria are met.

We could potentially do something like that, but it could also just slow down the search or cause more issues when we have to add edge cases after edge case. Though, there were still some issues complaining it wasn't as good as FZF still.

That said, it would improve the search further, since currently I don't think we do anything like this.

[badosu]

I've been using the regex strategy and it has worked well so far, so I think we can close this issue by me.

We can track improvements to the refinement process on https://github.com/onivim/oni/issues/1632, there it specifically targets multiple search items but we can discuss the refinement process as well.

Let me know if you think there are pending points to be addressed in this issue.