feat: make fs actions async

[yioneko]

All the fs actions are currently implemented as synchronous operations. This works fine with a small set of files and directories, but will block the user for a long time when working with a larger scale of files, e.g. removing a folder containing deep hierarchy and plenty of files like node_modules in javascript world.

The proposal is to replace the actions with the asynchronous version, mainly by using async luv apis as much as possible. This might lead to great improvements on user experience as the fs operations never block nvim. But it is also a potential breaking change if some users already rely on the synchronous behavior, I'm still not sure about it.

[alex-courtis]

I love this direction! Thank you for taking the initiative.

Unlike the filesystem watchers, these would be the one and only codepaths. The complexity of maintaining both synchronous and asynchronous is not desirable.

Let's be cautious and roll it out piecemeal behind (dark) feature flags.

Proposal: roll out a pilot for one operation. Rename is simple however is frequently used.

Possible breakdown:

  experimental = {
    async = {
      copy_paste = false,
      create_file = false,
      remove_file = false,
      rename_file = false,
      bulk = false,
      tree = false, -- needs to be broken down, perhaps build and refresh
    },
  },

[alex-courtis]

Consideration: schedule/debounce tree draw and refreshes. Thread safety around these operations is necessary for the new async paths as well as the existing (main thread) paths.

There is currently some work in that area #1836

[yioneko]

Oh, I'm not meant to cover async view rendering in this pr, and I think it might be better to be split into another pr as the impacting logic is much more than these file operations. Once this is done, that would be much easier to implement.

[alex-courtis]

Oh, I'm not meant to cover async view rendering in this pr, and I think it might be better to be split into another pr as the impacting logic is much more than these file operations. Once this is done, that would be much easier to implement.

That's a great approach.

Let's merge a PR for just one action to solidify the plumbing and prove the concept. I think rename is a good candidate. Happy to go with another action that you think is more appropriate.

Once we have proved the concept and user's have played with it (they will...) we can merge a PR with all the similar actions.

Following that we revisit refresh/draw in light of the changes in progress now.

[alex-courtis]

Superseded by #1870