QuickOpen is scoped to single folders/files/exact file path

[badosu]

Suppose you have a file with the same name on two different folders, for instance:

• signup/index
• signin/index

Usually I would type something like upindex or inindex to open that. This is a very simple example but for deeply nested files is incredibly useful, e.g. for a Rails project:

• app/models/user
• app/controllers/users_controller

I would type amouser and acuser to open each respectively.

It seems the current fuzzy finder is restricted to a single folder/file or the exact file path, so if I type models I get all model files, but if I type modelsu I get an empty list.

Not sure if this is hardcoded by ripgrep but would help me a lot if could be configured (or enabled by default), and one of the reasons I wanted to use a different fuzzy finder (apart from the previous case sensitivity issue, that was fixed).

I know for instance that this works as I expected on VSCode and all fuzzy finder plugins for vim I have used so far.

[badosu]

Seems like after further test I noticed this actually works, I'll see if it was a mistake on my test or some misconfiguration.

[badosu]

Ok, now I can confirm, weirdly enough if I type fast it breaks, if I type slowly it works.

[bryphe]

Ok, now I can confirm, weirdly enough if I type fast it breaks, if I type slowly it works.

Very strange! But that information is actually really helpful....

The menu change / migration to ripgrep allowed us to stream results instead of waiting for them completely. However, we had this logic (before we streamed) in our filter code:

oni/browser/src/Services/Menu/MenuReducer.ts

Line 101 in 26e6c00

const optionsToSearch = a.payload.filter.indexOf(s.filter) === 0 ? s.filteredOptions : s.options

Where, if we already had filtered results, we'd use those 'cached results' instead of filtering everything. That worked fine when we got all the results at once, but in this new world where we stream results, it causes us to lose results in the case you type fast (essentially we're ignoring any new results that come in).

Nice catch!

[bryphe]

#965 should take care of this, but it was hard for me to repro for sure. Let me know if you're still seeing it (or if you see a regression with performance).

[badosu]

@bryphe I am not having too much time in hands lately so I'll probably have to test it in the next stable release.

If I am able to test before I'll let you know, thanks!

[badosu]

@bryphe I tested in the new release, the feedback from the quickopen is much better now!

However the issue with the fuzzy finder is still present (not being able to find files with folders and filename matching the search).

Gonna take some time to present you with a repro repository soon.

[bryphe]

Awesome, thanks @badosu ! A repro repository would be a big help.

[CrossR]

I'd be interested in how this is now, I would hope its fixed with the changes we've made this year to the QuickOpen.

The only issue I can think of that would affect this is something like #2065, that is for paths with a space in the filter logic will kick in and mess it up.

[CrossR]

Since there is no other discussion on here, I'll optimistically close this out.
There is still some other issues (like #2065), but I think for the majority this is sorted now.

[badosu]

Thanks @CrossR, I missed this one!