Oni: Opening fuzzy finder in large directories.

[Bretley]

Occasionally I accidentally open Oni from my home dir, and it tries to recursively list everything in there. Once it's started, Oni becomes pretty much unusable. I don't know that there's a great fix for this, but it's annoying when I screw up.

[bryphe]

Yep, unfortunately the current strategy is synchronous:

                // replace placeholder ${search} with "" for initial case
                const files = execSync(overriddenCommand.replace("${search}", ""), { cwd: process.cwd() })
                    .toString("utf8")
                    .split("\n")
                this._showMenuFromFiles(files)
                return

The fix here would be to switch to executing the search command in an async manner, and streaming the results to the QuickOpen UI. That way the UI doesn't 'freeze up', and results can be accessed as we pick them up from the search command. In addition, it's common to cache locally recent results.

Thanks for opening the issue! This is definitely something that needs to be addressed.

[cyansprite]

I will try to look into this.

[cyansprite]

Looking into what strategy to use

[bryphe]

Looking into what strategy to use

Cool! I think the most important thing here is to be able to replace the execSync in getTrackedFiles and getUntrackedFiles - that'd be the first step.

The other part is, the way the Menu is currently structured, is it sort of expects to have all the items in one-go. I was thinking about changing the API a bit:

• Have an option to show some sort of 'loading' experience, so that the user knows that it is loading. Right now, we do that with an extra menu option, but it'd be nice to have this baked into the UI as something separate.
• Have the ability to add items as we discover them - this will make the experience much quicker and less painless, and is what most other fuzzy-finders do.

In addition, another goal would be to add caching, so that we can show items we've seen before right away.

Thanks for looking at this! Hope that helps - keep me posted if you have questions

[cyansprite]

I'm thinking about how we use quickopen and about files, bookmarks, and was playing around with an idea similiar to fzf.vim where quickopen will become an interface or abstraction and we have a bookmark , file , folder,
Buffer(s) lines, etc quick open. Trying to figure out if that would be a preferred strategy also adding files as they load instead of batch loading.

[cyansprite]

And yes first and foremost ditch the batch load :)

[cyansprite]

And yes the loading indicator shouldn't be a selectable item, put it on the left or right side of the text field or something and then go away or show a different icon after.

[cyansprite]

Just a preview of hey, I'm getting async to work :), this is a simple example but the point is, I'm getting there :).

[cyansprite]

Also I may implement to select more than one file

[bryphe]

@cyansprite - great progress! 😄 Very cool!

Is it possible to show the files as they are loading? It would be cool to be able to start selecting while the list is populating.

Also I may implement to select more than one file

Cool!

[cyansprite]

You will be able to :)

[cyansprite]

@extr0py You asked for files, I give you files
Probably should change how we load files into it... but hey it's cool :P

[bryphe]

Great to see the progress! Thanks for sharing the gif @cyansprite .

Ya, that 'violent scrolling' might be a bit jarring... it'd be cool to have some sort of progress indicator somewhere (or even just a counter of how many files we've indexed). Looks fast though!

[cyansprite]

Got rid of the scrolling, going to work on a number.

[cyansprite]

Number will be in a later PR I've never used React -.-

[bryphe]

This should be much improved with #793 and #764 - #764 brought in a streaming strategy, so that, instead of waiting for the finder process to complete to show results, we show them as they are streamed in via 'stdout' (and there is a loading experience). #793 brings in ripgrep which is faster than the default glob strategy for non-git repos.

I'll close this for now, but another item to look at is #571, and rationalizing how 'Open Folder' works (like, maybe in the case where a folder hasn't been explicitly opened, we don't try and search...) Goes along with some of the improvements called out in #635