Generic TreeDataProvider

[prabirshrestha]

I stumbled on this repo and seems like a really good idea. It is something I was planing to do in the future. I had even suggested something similar for vim to have vim/vim#3573 (comment)

It would be great if we have a generic plugin something like tree.vim which only cares about enabling other plugins to use the treeview. Similar to vs-code TreeDataProvider api - https://code.visualstudio.com/api/references/vscode-api#TreeDataProvider. Then can there be a plugin called tree-file.vim which only cares about file treeview. And it can be optimized for example starting a file watcher to make it more efficient. I would love to use it from vim-lsp so that we can have code tree view navigation.

I have started something very similar for a ctrlp.vim alternative - https://github.com/prabirshrestha/quickpick.vim It is at a very early stage.

[lambdalisue]

Yes. I made fila.vim to provide such generic tree viewer. For example, I would like to make a git repository viewer for a particular commit.

So what is your suggestion here? Do you want me to follow the TreeDataProvider API you've linked? Or do you mean that the current API is too difficult (have't documented yet).

[prabirshrestha]

I briefly looked into the code, haven't dug into it much but I saw references to process and files and posted this comment. I haven't played with the api so I cannot comment on if it is difficult.

My thought was if it would be possible to make it generic without any of those logic and support async by default (with callbacks and methods to modify the state for treeview). That way the core becomes very small and it only cares about rendering. It is the other plugins that can then hook into it. Also makes the maintenance very easy.

For example I could create a tree view for remote git repos, code hierarchy (namespace>class>functions), date tree view and so on.

Provide hooks such as on_expand, on_collapse, on_selection_change, set_busy and anyone can reuse it easily. For example in quickpick I provide those api and I don't care how sources fetch the data. It is just a UI component plugin. If they implement async they can call quickpick#set_busy(id, 1) to show spinner and internally they can either use neovim rpc or jobs or even pure sync vimscript. Quickpick doesn't care how others use it. Some of my thoughts are available in prabirshrestha/quickpick.vim#1 on what apis to add for quickpick which could be similar to treeview.

The reason I used vscode's api is because it works very well and is well thought. Though there are some extra things we need to add to make it better in vim. Since vim doesn't have Promise, I settled on generic callback and this allows pickers to implement whatever async libs they want. I'm creating one complicated picker and hence was looking for CancellationTokens and Rx in other threads.

[lambdalisue]

I briefly looked into the code, haven't dug into it much but I saw references to process and files and posted this comment. I haven't played with the api so I cannot comment on if it is difficult.

My thought was if it would be possible to make it generic without any of those logic and support async by default (with callbacks and methods to modify the state for treeview). That way the core becomes very small and it only cares about rendering. It is the other plugins that can then hook into it. Also makes the maintenance very easy.

Actually, that what I'm trying here.
Yes, fila.vim has codes for specific operations (file operations) but these codes exists only under autoload/fila/scheme directory and these codes are easily removed from this repository.

Provide hooks such as on_expand, on_collapse, on_selection_change, set_busy and anyone can reuse it easily. For example in quickpick I provide those api and I don't care how sources fetch the data. It is just a UI component plugin. If they implement async they can call quickpick#set_busy(id, 1) to show spinner and internally they can either use neovim rpc or jobs or even pure sync vimscript. Quickpick doesn't care how others use it. Some of my thoughts are available in prabirshrestha/quickpick.vim#1 on what apis to add for quickpick which could be similar to treeview.

The reason I used vscode's api is because it works very well and is well thought. Though there are some extra things we need to add to make it better in vim. Since vim doesn't have Promise, I settled on generic callback and this allows pickers to implement whatever async libs they want. I'm creating one complicated picker and hence was looking for CancellationTokens and Rx in other threads.

Currently, fila.vim rely on Async.Promise so I'm not sure about what kind of hooks are useful yet.
I may add some hooks in additions to Promise mech.

I haven't settled the API yet but the ideally plugin authors requires to follow the rules below to show tree via fila.vim (to create an external plugin of fila.vim)

• A node instance MUST provides an unique key in a tree (List)
• A node instance may have children method which MUST returns Async.Promise<List<Node>> instance
• A SCHEME must provide a root node instance for a URL
  • A root node instance MUST have children method

[lambdalisue]

Applied. Documentation is not yet available thought.

[lambdalisue]

https://github.com/lambdalisue/fern-bookmark.vim may help