search

wincent / command-t

⌨️ Fast file navigation for Neovim and Vim
BSD 2-Clause "Simplified" License
2.74k stars 318 forks source link

Make scanning non-blocking (ie. async) #421

Open idr4n opened 3 months ago

idr4n commented 3 months ago

Hi, I just started trying the plugin and although I really like how fast it find matches in normal size projects, when using these two commands at least (CommandT and CommandTFind) in the whole $HOME directory, it hangs for way too long until it opens up the window and show the results, blocking the whole neovim instance in the meantime.

Although it is not the case that I want to search my whole home directory, it sometimes happens (normally by mistake) that I don't realize I open neovim in the home directory and start searching for files. As point of comparison, Fzf.vim and FzfLua handle this very nicely and it doesn't block and I can cancel and quit right away, even I can search and it will start showing some results right away. Telescope on the other hand does stop scanning for files if I start searching but at least I can just close telescope and quit or do something else. CommandT, however, just block the neovim instance completely and I cannot stop the process or quit neovim (unless killing the tmux pane or closing the terminal).

It would be nice if CommandT handles very large directories in a similar way as Fzf that while it keeps scanning for files, I can still use the interface to some extend and even start searching and getting some results.

Not sure if this is something that can be achieve, but I just wanted to mention it nonetheless.

Gracias de antemano!

wincent commented 3 months ago

So, for now, the best way to mitigate this kind of thing is to set max_files as described in the docs. (This is assuming you're using the Lua implementation.)

I agree that it would be nice to be fully async, so I'm going to retitle this and think about it. The main problem with going async is that it may add overhead, so that is why I haven't done it in all these years, instead preferring to make the scanning as fast as possible to try and mitigate the downsides of doing the scanning in single-threaded mode. Note also that some of the alternative scanners might be faster than the default one, like the Ripgrep scanner, or the Git-based scanner, or the Watchman-based scanner etc. Those are mentioned in the docs too.

idr4n commented 3 months ago

Hi Greg, Thanks for suggesting that! Actually the max_files option does work for me and solve the primary issue of by mistake scanning very large directories and having the UI blocked. I added the suggested 100,000, and it takes maybe only two to three seconds for opening for me which is good in this case.

Since your suggestion solves the issue for me, feel free to close this or keep it open while considering to add the async if there are no downsides to it, as you wish.