Supports for nvim-tree over distant

[allencho1222]

Hi, I'm trying to enhance nvim-tree by using distant. Obviously, to fetch file trees of the directory in the remote machine.

I already passed simple test by abstracting file system API (luv.xxx and distant API).

However, the problem was:

1. nvim-tree uses per-file stat query (e.g., luv.fs_stat(filepath)) in the local machine (see this). However, this is inefficient in the case of distant because the latency caused by multiple network transactions (# of files in the directory) between the local and remote machine. To solve the problem, distant needs to fetch the metadata of all files in the target directory so that only one network transaction happens.

2. nvim-tree requires access permission for each file (e.g., luv.fs_access(filepath, 'R')) (see this). However, distant only fetches whether the file is readonly or not. I found that in the rust library, functions corresponding to luv.fs_access(filepath, 'R') did not exist according to this page. However, we might be able to use mode() (I'm new to Rust language and I'm not sure). Like 1, we need to do this by only one network transaction.

BTW, it seems that this issues is related to here. But, instead of batching commands, this issue insists that we need client query to fetch metadata of all files in the directory.

[chipsenkbeil]

When it comes to batch requests, the distant server supports this already and can be done when using the interactive CLI with JSON. The lua api doesn't offer this at the moment and the open issue is https://github.com/chipsenkbeil/distant/issues/63 for distant and https://github.com/chipsenkbeil/distant.nvim/issues/40 for distant.nvim.

[EDIT] Seems you've beaten me to referring to those issues. :)

The other issue of relevance would be https://github.com/chipsenkbeil/distant/issues/73, where we could support listing a directory and then chaining the results into a series of metadata requests, but that is a lot more work and needs a bit more thought into how it would be handled.

As for permissions themselves, Rust's standard library only exposes permissions that are cross-platform, which at the moment is the readonly flag. Do you know if fs_access is only used to check if a file can be read? In Rust, we'd use the unix-only portion of the standard library, PermissionsExt.

If you're needing to know the read, write, and execute permissions of a file, then that would either need to be a new request/response, augmented to the existing metadata (preferred), or do a hack for now involving submitting a ProcRun request to report back the status with something like ls -l that you'd have to parse locally.

If we made the data part of a new response (or augment the existing response), the read/write/executable flags would all need to be optional since some systems support that data and others don't.

Lastly, when it comes to reading the metadata of files within a directory, you could do a two network-call approach by first listing the directory files and then doing a batch request for each file's metadata. If we want to get it down to a single request, we'd either need #73 implemented in a way that could work or a custom response.

[chipsenkbeil]

I've opened up #86 to address the need for unix-specific permissions.

As another heads up, I'm considering switching distant.nvim back to using the JSON interactive CLI instead of a shared library. This won't affect the public API that the plugin provides, though. So, nothing that we build on top of the distant.nvim plugin should change in terms of public API compatibility.

[chipsenkbeil]

@allencho1222 I've added unix and windows metadata that can be returned, but haven't published a new release yet. I'll need to update the plugin due to some breaking changes, so expect it to be ready in a couple of weeks.

[chipsenkbeil]

Closing this issue out due to lack of activity. No warning here as everything needed to do this is now available in the binary and plugin.

[github-actions[bot]]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.