nvim-tree
[project management] direction of the plugin
I was wondering lately since neo-tree has gained a lot of attention, and seems to do basically everything that nvim-tree already does, that if i was a neovim beginner, it would be painful for me to choose between those two. Also, maintaining two plugins doing exactly the same thing is kind of a waste of time.
I think i'd like to make some performance analysis between the plugins, because the only reason i wrote nvim-tree in the first place was because nerd tree was too slow and there was not such thing as a lua explorer (and netrw didn't have some things i wanted such as git integration and file icons).
Although nvim-tree is pretty stable since it has a lot of users, i think we might want to reduce adding feature now that we have a good amount of them and i like things not being bloated tbh (which i feel neo-tree is actually starting to be).
I'd really like to focus on performance and memory consumption too, and globally the feel of nvim-tree being integrated into neovim. A good default experience, stability on the roof and performance.
Let me know what you think, i haven't yet tested neo tree, so i'm not even sure the comparison applies here :)
neo-tree
Playing
It has feature parity with nvim-tree plus:
- fugitive style git manipulation mode
:Neotree source=git_status - file nesting rules
It lacks a little polish e.g. :NeoTreeClose throws an exception if the tree was not opened.
The UI is attractive and pleasant to use.
Why Does It Exist?
I only learned about it ~a week ago, and my first thought was "why???".
It seems to be a rewrite of nvim-tree, however it takes a lot of inspiration and appears to have lifted a lot from nvim-tree e.g. git/utils.lua. The code looks a lot like nvim-tree, although I may be biased.
The functionality is almost the same, and one can be configured to look and act exactly like the other with minimal configuration tweaks.
Perhaps the author was not happy with the stability of nvim-tree, judging by the comments about breaking changes in the readme. There is heavy use of tags, although that seems to have hit the same problem we did: version tags are just not viable for vim plugins.
I am still confused; surely the author's time would have been better spent contributing to nvim-tree instead of being inspired by it.
Timeline
fs_event was added ~2022/01, which nvim-tree has only just matched.
legacy/deprecations was added at the same time as nvim-tree ~2022/03
filter/fuzzy finder same ~2022/06
This is very odd. neo-tree seems to be playing feature catchup with nvim-tree. It's not the other way around, as neither of us was aware of neo-tree.
Relative Merits Of neo-tree
+ tests: that is a big one
+ appearance: there are a few more options to tweak
+ stability: claims to be very stable
- doc: way too verbose, incomplete and poorly indexed
- onboarding: doc makes it is quite difficult to get started
- config UX: difficult to find what you want
The last three have been greatly improved for nvim-tree over the past 3-4 months.
I think i'd like to make some performance analysis between the plugins, because the only reason i wrote nvim-tree in the first place was because nerd tree was too slow and there was not such thing as a lua explorer (and netrw didn't have some things i wanted such as git integration and file icons).
We could do relative performance analysis by, say, adding nvim-tree's profiling to neo-tree. I'm not sure how useful that would be; we are focussing on performance improvements and there is no apparent performance difference between the two.
Although nvim-tree is pretty stable since it has a lot of users, i think we might want to reduce adding feature now that we have a good amount of them and i like things not being bloated tbh (which i feel neo-tree is actually starting to be).
I don't think we need to make any changes here. nvim-tree is very clear in what it does and what it won't do. We have not been adding any features that can be performed by another plugin.
We have been rejecting feature requests such as source code grokking.
The features that have been recently been added such as filters / bookmarks add to the value of the tree and are requested by users.
RE bloat: most nvim-tree features are optional and do not intrude on the user experience.
I'd really like to focus on performance and memory consumption too, and globally the feel of nvim-tree being integrated into neovim. A good default experience, stability on the roof and performance.
Watchers and git/diagnostics throttling have been beneficial. #1429 is the next logical step.
Stability
We have achieved stability both when adding features and making fixes. We have greatly improved over the last few months and we are good at it.
I don't even think we need the nightly tag; it's only updated when one of us remembers.
master is stable, however we are still pushing some changes directly. I think we should stop pushing all but obvious bugfixes. We should branch / PR even just for a quick test, if not a full review. We do not have to hurry any more.
Testing
I've been putting off thinking about this for a while now.
I have many decades of experience working on projects with a variety of test coverages. There is no right answer. The cost of tests is always higher than you initially estimate.
Full coverage is almost never the right answer and definitely not in nvim-tree, with its heavy interaction with the vim API.
I'll start thinking about what we could test for maximum value, as well as what has caused problems in the past.
Thank you for doing this. I don't think neo tree copies nvim-tree code or tries to accomplish the same feature set, but since it's stated in the readme:
Everything I know about writing a tree control in lua, I learned from: nvim-tree.lua
I don't mind. The only thing that bothers me a bit is that indeed doing twice the work just for the sake of "stability" is a bit too much.
The thing is, the neo-tree codebase seems a bit cleaner than nvim-tree (ofc, this makes sense), and i wonder if we could avoid maintaining two separate plugins for this since this makes no sense to me tbh. Its just duplicated work. Also another thing, but testing would frankly just adds unecessary burden.
I use tested and not tested neovim plugins, i cannot say tested neovim plugins are more stable. We have testing in nvim-treesitter because a small change can have quite an impact on a language integration as a whole, even with that, there are a lot of bug reports coming from users. Also i think the architecture/design patterns of nvim-tree don't help with testing, the integrations are pretty tightly coupled with the code, and that would slow down even more the testing process. I value fixing a bug in a small amount of time more that spending time trying to test something just for the sake of not breaking it in the future. We should be careful but bugs happen anyway.
If i test, i usually go with tdd, but in the case of neovim plugins, i've tried this approach and its quite hard to do since testing neovim integrations is quite verbose (and this is ~30% of a plugin). You need to apply some sort of layered architecture and you have a lot of additional code for patching the different layers together and it gets quite annoying to work with :smile:
After all, i just don't like duplicated work, i don't mind if neo-tree takes a different approach than nvim-tree that is clear for the users, but if its just about "stability" and "breaking change", i think we should have a talk with the maintainer, because it only clouds clarity in the neovim ecosystem space. I really don't like projects that duplicate the work, i feel very frustrated with all those "yet another...". As a developer, i try to develop things that don't exist yet, or improve things that do exist. Also i believe we have a pretty stable way of doing things now, and i'm not sure neo-tree's approach works anymore.
If i test, i usually go with tdd
Agreed. Retrofitting is always difficult when functions are not built for test.
I use tested and not tested neovim plugins, i cannot say tested neovim plugins are more stable.
No tests is quite acceptable.
If i test, i usually go with tdd, but in the case of neovim plugins, i've tried this approach and its quite hard to do since testing neovim integrations is quite verbose (and this is ~30% of a plugin). You need to apply some sort of layered architecture and you have a lot of additional code for patching the different layers together and it gets quite annoying to work with 
Testing anything that hits the vim API or is user interface is not worth the effort.
My preferred test strategy: no tests, or isolate a small number of critical paths and test them only.
i think we should have a talk with the maintainer
Yes. Understanding the author's motivations would be of great assistance.
Are you happy to open the conversation?
A conversation with the neo-tree author. Perhaps we could discuss:
- Motivation for building neo-tree rather than collaborating on nvim-tree
- Future plans for neo-tree: features and internal enhancements
- Ways we might collaborate, such as sharing performance boosts
- Merging neo-tree and nvim-tree
- Experiences with the additional effort required for testing
I think all of the above are positively framed and useful for both trees.
i will probably be away from the computer for the month of august, so i think we can start this discussion in september, this way if neo tree came up with new features or so, we could reconsider.
i will probably be away from the computer for the month of august, so i think we can start this discussion in september, this way if neo tree came up with new features or so, we could reconsider.
Enjoy your time off.
I won't make any PRs during that time.
What do you want me to do with user PRs?
seems reasonable, thanks you can merge them if you feel they are correct, and they might not break something. I think it should be pretty calm during August anyway :)