Fzf-lua no longer dependent on nvim-fzf

[ibhagwan]

Hi @vijaymarupudi,

Just wanted to say thank you very much for your wonderful work on this plugin, as of this commit https://github.com/ibhagwan/fzf-lua/commit/f8b447dbbd7ca5b46ded2fd26f0bf9c94cce352e fzf-lua is not depedent anymore on this plugin.

It is important for me to let you know through this issue and understand the reasons for this asnvim-fzf still (and always will be) the barebones of fzf-lua and the main reason why I even started on this journey, I hold you (and your code) in the highest regard and appreciate everything you've done.

Ok, now to the nitty gritty... for a long time I've been struggling making fzf-lua more performant and responsive, although not very apparent on small codebases it was really annoying on large ones, even with zero processing the fact that all the libuv work was done in the same process was causing noticeable delays.

I went through many routes, tried almost every trick in lua/neovim "book" (coroutines, processing over RPC, etc) to no avail, the mere fact a blocking operation (think string.gsub, string.match) was running on the main process was causing UI hangs and other unpleasant phenomenons (for exmaple, https://github.com/ibhagwan/fzf-lua/issues/211).

Eventually I realized there was no other (and better way) than separating the process altogether (effectively lua "multi-threading") and running neovim as an external shell command with zero depedency on the running instance, so that running an fzf-lua command would be equal to the shell version, something like:

# both commands should have equal results and print to stdio
# with the neovim version capable of line processing internally
fd | fzf
neovim --headless --clean `lua ... 'fd'` | fzf

Unfortunately, the more I experimented trying to solve this the more nvim-fzf core code changes were required (esentially rewrite of the llibuv parts) and it made no sense to PR my "hacks" into nvim-fzf (for exmaple, writing into the mkfifo pipe externally) so overtime the code drifted to slight incompatibility with nvim-fzf to the point where I'm now planning a new architecture to offload all functionality to the external process so everything is basically an external piped shell command.

If you feel like reading more about this, it's detailed in https://github.com/ibhagwan/fzf-lua/issues/248.

In the hopes you don't find this offensive (or maybe even some parts useful for nvim-fzf?), nvim-fzf code and references will live on inside fzf-lua :-)

[vijaymarupudi]

I view this as excellent news, the true spirit of open source taking place! Appreciate all your feedback and issues getting this library to a stable place (given the current design). The external shell command idea is excellent and I can't wait to see how it works out. I use fzf-lua everyday and will continue to do so. nvim-fzf will still probably be my go-to for my personal commands that aren't in fzf-lua.

I doubt I have the maintenance time to attempt the multiprocess architecture myself, but who knows, maybe one day I'll have to archive nvim-fzf because fzf-lua can do all that it can and more, faster :)

[ibhagwan]

This makes me so happy to hear, tysm @vijaymarupudi !

the true spirit of open source taking place

Love this :)