Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Vim

lwn.net

Post reply on HN
Print view View original

61–70 of 203 posts

Re: The State of Vim

#61

Post by PreHistoricPunk »

dmortin wrote: post #4

I wonder how long vim and emacs can stay vibrant. I've used emacs in the last 20 years, so I stick with it, but new generations who are trained on vscode and such are less likely to use such "old fashioned" tools. Surely, there will still be emacs and vim users 50 years from now, but the user numbers and the community power will diminish as the graybeards gradually leave this plane.

Speaking for myself, I only used Neovim because of its modularity and the keybindings. Imho, everyone should give the basic Vim keybindings a chance at least once and see if they like it.

At this point, however, I do not really use Neovim anymore. I switched to Zed, the Vim emulation is pretty good and customizable and most functionality I want is already there along with incoming support for Jupyter Notebooks. VSCode also has these features.

It is fun to use Vim/Neovim but unless I need to use it, I doubt I will return to it.

Re: The State of Vim

#62

Post by BiteCode_dev »

Maken wrote: post #60

>he started adding more potentially controversial changes, such as support for the XDG base directory specification It feels like every single user-facing open source project needs to have its own XDG drama at some point.

I don't understand how it's a drama. It's an old spec, it's easy to follow, it's standard, and you can still keep compact with the old .dir at user root if you want.

What's the big deal ?

Re: The State of Vim

#63

Post by myaccountonhn »

openmarkand wrote: post #30
porphyra wrote: post #11

Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.

I have tried several times and I always switched back to vanilla vim. Neovim has various nice features but it requires a lot of time to migrate correctly IMHO. 20 years of habits are hard to leave, I think. Sure the configuration file is retro compatible, but some of the plugins are better suited for neovim and vice versa. I use a dozen of them and if I switch permanently to neovim I'd like to start fresh using more…

I found the neovim community to operate a bit like the node ecosystem, you pull in a plugin for every problem that solves already solved problems their own way. The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting. That said I think people should use what they like, and I am happy that there is a big community developing an alternative to VSCode. I just didn't feel it was for me.

I ended up moving to Kakoune. The community is small but the tool is so much better designed and integrates well with unix. That means that i can usually glue together whatever I need myself with 1-3 lines of config and don't need an entire plugin when I want something that isn't built-in.

Re: The State of Vim

#64

Post by normie3000 »

johnnyanmac wrote: post #55
flohofwoe wrote: post #29

Earlier quoted context omitted.

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge ac…

> potential rouge actors

Communist assets?

Re: The State of Vim

#65

Post by vlovich123 »

johnnyanmac wrote: post #55
flohofwoe wrote: post #29

Earlier quoted context omitted.

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

It's the best, when you find one. But the approach is also the riskiest. You may not even pick a BDFL to begin with (I'm sure many of us can name certain repos overly held back by a bad or muddy vision, or being overly conservative with feature/pull requests) . or that B fades away for any number of factors. Committees sacrifice that cohesive vision and agility for being able to have some checks to potential rouge ac…

This is what another commenter wrote:

> Braam really took Neovim personally and got better at getting stuff into vim that he wouldn't merge before once neovim was arround as a competitor. I really lost track of vim in the last years because neovim is just a solid platform with an active community.

I think that's the answer - the specific makeup of any given team isn't as relevant as competition which spurs competitors to either keep up or the more successful upstarts to take over.

Re: The State of Vim

#66

Post by Propelloni »

fsloth wrote: post #50
psychoslave wrote: post #34

Earlier quoted context omitted.

Unless your software deals with tracking people within an organization that will of course comply with the political parties that rule the regions where there software operate.

If Vim tracks you then that’s a willfull act that breaches trust. IMO no governance model can defend against supply chain attacks. IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best. Not because they have perfect knowledge or are the best but because dictator led…

Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects that do not use a BDFL I'd wager that the perceived superiority of BDFL can at least in part be attributed to the perennial hero worshiping we like to do.

[1] https://en.wikipedia.org/wiki/Benevolent_dictator_for_life

Re: The State of Vim

#67

Post by flohofwoe »

Propelloni wrote: post #66
fsloth wrote: post #50

Earlier quoted context omitted.

If Vim tracks you then that’s a willfull act that breaches trust. IMO no governance model can defend against supply chain attacks. IMO you shouldn’t try to fix things with governance model which it doesn’t fix. Use a governance model that leads to good governance. In technical and creative work single highest point of authority is best. Not because they have perfect knowledge or are the best but because dictator led…

Hmh, I don't have a case study at hand, but there are many reports (and management self-help literature) where teams are shown to be the superior approach to complex situations, especially in software development. Furthermore, considering that there are only about 50 identified open source projects out there with a BDFL [1] and only a few of them are clearly best-of-breed, while there are many best-of-breed projects…

Any tiny project on Github, Gitlab, ... which is maintained by one person but accepts PRs and feedback from outside contributors is essentially a BDFL project.

The single project owner decides what goes and doesn't go into the project by merging or rejecting PRs. People are still free to maintain their own forks with contributions that are not accepted into the main version.

In a way, the entire Github workflow is built around the idea of BDFL managed projects.

Re: The State of Vim

#68

Post by pjmlp »

porphyra wrote: post #11

Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.

That is the only reason why while being on Emacs side, on the whole Emacs vs vi, I ended up learning enough vi to be productive on customers' UNIX systems.

Re: The State of Vim

#69

Post by flohofwoe »

eviks wrote: post #31
flohofwoe wrote: post #29

Earlier quoted context omitted.

You need someone to say 'no' to all the stupid ideas, and also to the occasional good idea to stay focused. Committees and communities are quite bad at that. IME the BDFL model has mostly worked best for open source software development, unless the BDFL is a complete ass of course. (also software projects don't need to be democracies, e.g. people won't starve or sent to the gulag if things go sideways)

Saying "no" is the easiest job in the world, and committees are pretty good at it. That's why we have decades-old design failures everywhere, because saying "no" to an improvement is so much easier that doing the actual governing and resource allocation to see it through, especially with volunteers And given the article describes big fails at basically every aspect of project management (from github account to money…

> Saying "no" is the easiest job in the world

On the contrary, saying No to an otherwise great contribution that doesn't fit into the longterm vision of a project for one or another reason is the hardest thing in the world.

Re: The State of Vim

#70

Post by wruza »

porphyra wrote: post #11

Many of the Vim nerds I know, including myself, have switched over to Neovim. Only when using a remote server with a default installation do I use regular old Vim.

Neovim turned itself into a pop-blink IDE which some people never wanted. It's good that it serves the needs of its fans, but it's also good that Vim stayed in its own tracks. Losing Vim as it is would be a great loss for many.
Post reply on HN