I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
Prior to 0.9 (if I recall correctly), you had to install a plugin to be able to interface with LSP servers, and in 0.9 they integrated the support into NeoVim itself.
Unfortunately I don’t remember what episode it was or even if it was specifically on an episode of The Standup, or if it was some other video that he and ThePrimagen did outside of The Standup.
Original HN post here if you’re interested. https://news.ycombinator.com/item?id=7279358
I've always wondered what this legend is doing now
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
The entire software development world would be much simpler if nobody needs new features, bugs and CVEs don't exist, or "just pin the version" works.
> "can't do things since there are no plugins yet"
Depending on what I am doing, I will probably go back to VSCode to get things done. Terminal editors are nice, but VSCode's extension ecosystem and usability is unmatched. I speak of that as someone who has spent hundreds of hours developing VSCode extensions. For me, "can't do things" is not (necessarily) a reason to set up Neovim plugins. It means I should figure out 1) if that's something I need to do regularly 2) If so, what's the best way to get it done.
(I am very well aware of what you can do with vim/Neovim plugins, just like zsh and tmux etc. Not spending time hand writing my config or setting up my plugins is an intentional choice. I like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Your arguments here are valid, for a particular kind of person who values a particular kind of workflow.
Some of us would rather use vi than vscode. If you take away the plugin ecosystem, the core value is still there.
So not the red-herringly 10 min (and there are hundreds of keybinds, so the initial learning wasn't 10 min either)
> like to start with a commonly used setup, discover pain points and bottlenecks, and then optimize or find some other solutions.)
Which you've presumably already done at least twice with vim and VSCode, so again it's just a waste of time to start from scratch yet again instead of configuring for the things you know you need
At this point I just want a decent Helix-Evil-Mode.
> 0.13 “The year of Batteries Included”
> 0.12 “The year of Nvim OOTB”
Almost all such complaints are close to “I want to be cool and be seen as an haxor, but all I know is a bit of VSCode and IDEA, make it easier for me, plz”.
However, Neovim explicitely states that they don't want to turn VIM into an IDE. The feature parent is talking about seem to be falling into that type of vertical integration instead of composability.