Welcome to fzfx.nvim Discussions!

[linrongbin16]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[asmodeus812]

Hi i wanted to ask a few questions regarding the technical impl. of the plugin. Looking at the implementation i could see that for the provider decorators and previewers we are using separate standalone nvim instances to run the tasks that a provider or previewer would do (e.g. like the icons decorator / transformer, and write to the providers results pipe), in a non-blocking manner, parallel to the main nvim instance, leaving the main instance responsive while fzf is fed the data from the pipes.

Which is great, however having this information i am wondering why are some (lsp_references) pickers, fetching results wiht buf_sync, i am often working with code bases where references would return a ton (2k +) results and the server is slow enough as it is already, the fzfx ui opened, but it is blocking until the server responds, would it not be better to have those lsp providers be using the async versions of client.request ?

In general the non-blocking nature of the decorators could also be extended to more than just generating the lines with icons i imagine ? Could we have most of the heavy processing / transformations (per a line) be moved as provider decorators, are there any limitations ?

Taking lsp_refernces as an example, instead of using the main nvim instance to traverse the result table, and do most of the transformation in there, could we not pass each reference entry to a decorator to process it, instead of doing the bulk of the work in the main nvim instance first ?

[linrongbin16]

hi @asmodeus812, you are correct, because current implement of provider is running in sync mode.

I will improve this by introducing the lua coroutine, to make it async.

[asmodeus812]

@linrongbin16 thanks, sound really good. Have you considered instead of coroutines the following approach for achieving totally independent provider, that is not going to run on the main nvim instance

• fzf bind:start/reload spawns a nvim headless with the the bin/provider (as it does now)
• that headless instance calls in the provider using the registry reference from the main nvim instance (as it does right now)
• here instead of the provider processing / looping over the data (e.g. the lsp-references, symbols etc, this mostly applies for in-memory lists/tables which could be huge and expensive to loop through) in the main nvim instance, in the provider callback, we do only a single rpcnotify in the provider instead, to the headless instance that we came from, we are going to send it the data to process instead, since the rpc communication is msgpack, that should be quite fast, the provider callback does not perform any work, but the rpcnotify. The headless instance now receives the notify, from the main nvim instance, with the data to filter, does all the job (just like now how it only does the decorator work there atm, what i suggest, is the entire processing / filtering / reduce instead), outputs each entry to a pipe, fzf picks it up and displays it.

[linrongbin16]

hi @asmodeus812, the provider function will need to run by the nvim editor people are using, some provider will have to collect data from the nvim editor, for example FzfxBuffers.

[asmodeus812]

Imdeed, however remember that fzf bind:action would start off the child instnave, then from the child instance rpcrequest (sync) to the parent main instance provider by registry id, before we rpcnotify back the child we can collect the dat, simce we are now in the main instance, to be sent, in this case tbl_map the current opened buffer ids into a table of buffer fields needed for the processing of the buffer fzf picker (buf id, buf name for example). Then, rpcnotify the child with that buffer tbl and let it do its filtering and decorating.

Buffers picker is not as heavy / comtains at most a hundred or so entries at worst. usually to take great advantage of this, but a lot of lsp responses are.

[linrongbin16]

For now the data flow is:

Case-1 FzfxFiles

1. User press <space>f
2. invoke the User Command callback
3. prepare context (mainly contains current buffer/window information where user's cursor is at)
4. prepare fzf binary's options, calculate popup window size/position
5. launch the nvim float window, e.g. the popup window
6. open terminal inside the popup window, run the prepared fzf binary command as a shell command
7. the FZF_DEFAULT_COMMAND (the searching command fzf is using) is actually a nvim -l xxx/provider.lua
8. inside the provider.lua, it rpcrequest the main nvim editor (the editor user is using).
9. nvim editor run the provider lua callback function, and returns the fd . -cnever -tf -tl -L -i shell command to provider.lua.
10. provider.lua wait for nvim editor's response
11. provider.lua got the returned shell command (e.g. fd . -cnever -tf -tl -L -i), and execute it, and print the output to terminal.

I think I didn't move the step-9 before launching the popup window (step-6), is simply because I didn't notice the performance issue before.

If this is your point, yes, it looks like it can be improved.