Feature request: support async LSP file operations

[sudopseudocode]

Thank you for your work on this plugin, it has been working very well for me with nvim-tree so far!

I'm not sure how difficult this would be to support, however I think it would be a killer feature to support asynchronous LSP file operations. Currently, when renaming a file (especially in a larger codebase) it may take several seconds to complete the LSP file operation.
Since this is happening synchronously, it blocks the UI for several seconds until the action is completed.

Opening up this ticket here to at least start a conversation of the feasibility of supporting async LSP file operations in order to unblock the UI until the file operations are completed. Ideally once complete, it would have nvim-tree/neo-tree refresh with updated files.

[antosha417]

Hey @pauldiloreto,
Thank you for your kind words and for opening this discussion.

From an LSP perspective, making it asynchronous is certainly feasible to support asynchronous LSP file operations. Here's a high-level overview of the approach:

1. Send "will rename" request to the LSP server.
2. After response apply the workspace_edit provided by the LSP server.
3. Actually move the file.

The reason I implemented this feature synchronously is because once we exit the callback, nvim-tree would immediately move the files without waiting for response. However, workspace_edit from the LSP server contains old filepaths, so it can't be applied to moved files.

To address this, we have a few potential solutions:

• We can consider patching the workspace_edit ourselves and then applying it correctly. But I'm afraid there can be a ton of corner cases there.
• We could provide a different API to handle these operations in an asynchronous mode, either within nvim-tree or through an alternative approach. For example Expose a lua API or ex commands for renaming without nvim-tree? #13
• It may also be worth discussing the possibility of introducing support for async callbacks in nvim-tree with the maintainers.
• There is also did rename files notification in lsp spec. We can move the files around from nvim-tree and after the move notify lsp server that we did it, so it will fix the code. The problem with this that I didn't see any server that implements it. So would need to contribute it to lsp servers of interest. But I looked more than a year ago, maybe things changed.

I want to be transparent about my current availability - I don't have much free time to work on this feature in the near future. However, I'm more than willing to collaborate or guide anyone interested in implementing this improvement. Contributions from the community are highly appreciated, and I'm here to offer assistance as needed.

Let's keep this conversation open and see if we can find a way to enhance the user experience with lsp.

[sudopseudocode]

It may also be worth discussing the possibility of introducing support for async callbacks in nvim-tree with the maintainers.

This seems like the best approach imo, but sounds like it may take some time to get alignment on necessary changes and getting those merged as a dependency for this feature.

There is also did rename files notification in lsp spec...

I like this idea too, but would be even more effort to contribute to multiple LSP servers to support this spec. Since this could be handled with the above solution of having nvim-tree support async callbacks, I think that makes the most sense for now. I'm sure there would be several other use cases where nvim-tree would want to support async callback anyways.

Appreciate your transparency about availability. I think we can all relate to this.
I also have limited availability for the next few weeks or so, but I'd be happy to help contribute to this at some point!

[mehalter]

@antosha417 there actually are quite a lot of language servers that implement the didFileRename. vtsls which is an LSP connector for the VS Code typescript plugin, OmniSharp for C#, and the Lua Language Server all support updating imports on didRenameFiles notification rather than the willRenameFiles request. I don't know of any language servers that implement both though. I actually opened up a PR to add this didRenameFiles support into the plugin just so we could get import renaming for more language servers in this plugin (#25). I also looked into trying to make an async implementation for the willRenameFiles implementation and there really isn't a good one that I can think of.