5 ms·

It probably goes against Vim tradition, culture and freedom to choose, but I wish they added even more built-in features (like Helix) that are currently impleme

by imjonse 6mo ago

It probably goes against Vim tradition, culture and freedom to choose, but I wish they added even more built-in features (like Helix) that are currently implemented in competing and sometimes brittle plugins and have to be put together into also competing vim starter packs and distros of plugins and config files just to have a modern setup out of the box.

skydhash 6mo ago
Define “modern”! 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”.
- Sayrus 6mo ago
  I think what they did with first-party support for LSP would be an example of this. 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.
augusto-moura 6mo ago
I believe neovim started as a fork specifically to implement features like LSP support and package management, VIM eventually also caught up. But i don't believe anything is out of the table, or against Vim tradition. Which features do you want to see built-in, specifically?
- QuantumNomad_ 6mo ago
  I’m also pretty sure that on an episode of The Standup, one of the Neovim core maintainers TJ DeVries (Teej) said that it is a good idea to prove new ideas in the form of a plugin rather than submitting pull requests for Neovim itself with new ideas that have not yet been tested out and proven in the real world. Implicitly implying that indeed Neovim is open to bring features from plugins into core Neovim itself, if they are proven to be useful for a lot of people. 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.
  - GCUMstlyHarmls 6mo ago
    This is essentially how the new package manager got done. `mini.deps` was created as basically a proposal for a built in package manager (beyond also just being its own thing), sat in the wild for a year or two then a derived version got imported.
- aidos 6mo ago
  Multi threading, but yeah. Original HN post here if you’re interested. https://news.ycombinator.com/item?id=7279358 https://news.ycombinator.com/item?id=7279358
  - mi_lk 6mo ago
    > The author of NeoVim (Thiago de Arruda) I've always wondered what this legend is doing now
lawn 6mo ago
Neovim is actively moving in that direction.
gorjusborg 6mo ago
I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.
- Blackthorn 6mo ago
  Not to talk about the other side of the holy war too much, but one of the things I appreciate about GNU ELPA is it's treated as part of the Emacs distribution and needs to follow all the rules of Emacs proper as a result.
- qudat 6mo ago
  There is zero reason not to include a picker like helix does. I’m gonna guess 90% of everyone running neovim has a picker
  - Blackthorn 6mo ago
    Does ex not count?
  - amitds1997 6mo ago
    It's on the roadmap. https://github.com/neovim/neovim/issues/35456 https://github.com/neovim/neovim/issues/35456
  - gorjusborg 6mo ago
    I believe we are thinking about different time horizons, and your language and comparison to <modern editor> reveals a lot about unsaid about your reasoning. 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.
bheadmaster 6mo ago
This is what happened with the Language Server Protocol. 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.
- shmerl 6mo ago
  Would be nice to also have such support for DAP, though nvim-dap is doing a good job so far.
g947o 6mo ago
Which is why I just went with Helix and learned their keybindings. I have much more important things to do than figuring out why a plugin stopped working.
- goosejuice 6mo ago
  Just pin the plugin or don't use it.
  - g947o 6mo ago
    Not a choice if you need a specific new feature or a certain fix. 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.
  - thayne 6mo ago
    Neovims API isn't (yet) fully stable. So updating neovim could also break a plugin.
- eviks 6mo ago
  Doesn't seem like it if you can waste time learning all the keybinds just because you switched an editor, but also how does "can't do things since there are no plugins yet" rank higher vs "sometimes stops working" in importance?
  - ratrace 6mo ago
    [dead]
  - g947o 6mo ago
    It took me about 10 min to learn the keybindings. It does take longer to get familiar and efficient with them, but I wasn't a Vim master to begin with. (I can navigate efficiently and am proficient with a few combinations that I use the most, but that's about it.) > "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.)
jatins 6mo ago
There are lot of readymade neovim configs you can copy. I was experimenting recently with lazy.vim and took a git clone and cp command to get up and running
jrop 6mo ago
As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]"). 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. [1] https://github.com/jrop/morph.nvim https://github.com/jrop/morph.nvim
bulbar 6mo ago
That's why I stopped using it. Didn't want to have "reconfiguring an editor to be an IDE" as a hobby.
eviks 6mo ago
But this isn't vim, so doesn't go against those? > 0.13 “The year of Batteries Included” > 0.12 “The year of Nvim OOTB”
- imjonse 6mo ago
  nice to see that.
red_hare 6mo ago
I love the batteries included in Helix. Just the right amount that I don't need much else. At this point I just want a decent Helix-Evil-Mode.

by imjonse 6mo ago

skydhash 6mo ago

Define “modern”! 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”.

Sayrus 6mo ago
I think what they did with first-party support for LSP would be an example of this. 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.

augusto-moura 6mo ago

I believe neovim started as a fork specifically to implement features like LSP support and package management, VIM eventually also caught up. But i don't believe anything is out of the table, or against Vim tradition. Which features do you want to see built-in, specifically?

QuantumNomad_ 6mo ago
I’m also pretty sure that on an episode of The Standup, one of the Neovim core maintainers TJ DeVries (Teej) said that it is a good idea to prove new ideas in the form of a plugin rather than submitting pull requests for Neovim itself with new ideas that have not yet been tested out and proven in the real world. Implicitly implying that indeed Neovim is open to bring features from plugins into core Neovim itself, if they are proven to be useful for a lot of people. 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.
- GCUMstlyHarmls 6mo ago
  This is essentially how the new package manager got done. `mini.deps` was created as basically a proposal for a built in package manager (beyond also just being its own thing), sat in the wild for a year or two then a derived version got imported.
aidos 6mo ago
Multi threading, but yeah. Original HN post here if you’re interested. https://news.ycombinator.com/item?id=7279358 https://news.ycombinator.com/item?id=7279358
- mi_lk 6mo ago
  > The author of NeoVim (Thiago de Arruda) I've always wondered what this legend is doing now

lawn 6mo ago

Neovim is actively moving in that direction.

gorjusborg 6mo ago

I agree in principle that absorbing the best from the ecosystem is good. However, anything pulled into core should have a long lifetime and be considered part of the API. This deserves careful consideration, and plugins work really well until it is clear there is a reason to pull something in.

Blackthorn 6mo ago
Not to talk about the other side of the holy war too much, but one of the things I appreciate about GNU ELPA is it's treated as part of the Emacs distribution and needs to follow all the rules of Emacs proper as a result.
qudat 6mo ago
There is zero reason not to include a picker like helix does. I’m gonna guess 90% of everyone running neovim has a picker
- Blackthorn 6mo ago
  Does ex not count?
- amitds1997 6mo ago
  It's on the roadmap. https://github.com/neovim/neovim/issues/35456 https://github.com/neovim/neovim/issues/35456
- gorjusborg 6mo ago
  I believe we are thinking about different time horizons, and your language and comparison to <modern editor> reveals a lot about unsaid about your reasoning. 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.

bheadmaster 6mo ago

This is what happened with the Language Server Protocol. 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.

shmerl 6mo ago
Would be nice to also have such support for DAP, though nvim-dap is doing a good job so far.

g947o 6mo ago

Which is why I just went with Helix and learned their keybindings. I have much more important things to do than figuring out why a plugin stopped working.

goosejuice 6mo ago
Just pin the plugin or don't use it.
- g947o 6mo ago
  Not a choice if you need a specific new feature or a certain fix. 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.
- thayne 6mo ago
  Neovims API isn't (yet) fully stable. So updating neovim could also break a plugin.
eviks 6mo ago
Doesn't seem like it if you can waste time learning all the keybinds just because you switched an editor, but also how does "can't do things since there are no plugins yet" rank higher vs "sometimes stops working" in importance?
- ratrace 6mo ago
  [dead]
- g947o 6mo ago
  It took me about 10 min to learn the keybindings. It does take longer to get familiar and efficient with them, but I wasn't a Vim master to begin with. (I can navigate efficiently and am proficient with a few combinations that I use the most, but that's about it.) > "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.)

jatins 6mo ago

There are lot of readymade neovim configs you can copy. I was experimenting recently with lazy.vim and took a git clone and cp command to get up and running

jrop 6mo ago

As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]"). 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. [1] https://github.com/jrop/morph.nvim https://github.com/jrop/morph.nvim

bulbar 6mo ago

That's why I stopped using it. Didn't want to have "reconfiguring an editor to be an IDE" as a hobby.

eviks 6mo ago

But this isn't vim, so doesn't go against those? > 0.13 “The year of Batteries Included” > 0.12 “The year of Nvim OOTB”

imjonse 6mo ago
nice to see that.

red_hare 6mo ago

I love the batteries included in Helix. Just the right amount that I don't need much else. At this point I just want a decent Helix-Evil-Mode.