Live data from Hacker News

The State of Vim

lwn.net

81–90 of 203 posts

Re: The State of Vim

#81
post #19

Earlier quoted context omitted.

I went back and forth quite a lot until i decided to stick to vim. The reason being that I want to gain deep knowledge of my editor instead of depending on a gazillion plugins that occasionally break. Now, I understand this is something you can do with both vim and neovim, however the documentation of neovim is littered with both the vim docs and the new lua docs, and there is a vibe of "you already know all of vim,…

I did the same. I mostly use Vim without plugin and a simple vimrc file. For the heavy stuff and big projects I use VSCode.

:s/VSCode/Jetbrains/

Re: The State of Vim

#83
post #70

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.

I just set up a Neovim configuration from scratch and I have no idea what you are talking about. I did install a completion plugin literally called blink, but even that supports keybinding activation.

Re: The State of Vim

#84
post #75

Earlier quoted context omitted.

Something pops out and blinks on itself while you are typing. At least that's what I've seen in neovim "ads" videos back in the day.

Very annoying. I decided to move from manually creating my own config to using Astronvim and there were just so many distracting things in the default installation. The good thing is that you can disable what you don't want - which I did. The bad thing is that finding the right option or the actual plugin that is bringing the functionality you don't want takes some time.

Was the prebuilt configuration worth it in the end then? I recently started a from-scratch config and followed kickstart, which is pretty minimal and also not a plugin/distribution/self-updating thing, it’s just an example config file you can copy.

Re: The State of Vim

#85
post #70

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.

> Neovim turned itself into a pop-blink IDE

What does that even mean? Just sounds like a lazy and false argument.

Re: The State of Vim

#86
post #31

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…

I agree, committees are good at saying no. They tend to say no to two not perfect ideas and then force a consensus containing most often the worst aspects of both original approaches. The good news is that the result is so bloated that can‘t be changed and so provides a stable foundation for years of misery.

There are counter examples of course but the power dynamic of committees is not conductive to results that have properties desirable in software.

Re: The State of Vim

#87
post #25
post #7

Earlier quoted context omitted.

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.

I wonder, will there be something to emacs, as nvim is to vim?

sacrificing all existing elisp code makes a new editor worthless, maintaining compatibility makes it extraordinarily hard to get anywhere.

Re: The State of Vim

#88
post #25
post #7

Earlier quoted context omitted.

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.

I wonder, will there be something to emacs, as nvim is to vim?

There’s (arguably) an argument to be made that Emacs configuration distributions fit that niche - Doom Emacs, Spacemacs, and Prelude provide varying flavours for different kinds of Emacs users.

Apart from that, I don’t really know what an application would be to Emacs as nvim is to Vim. It’s more like nvim is to Vim what Emacs is to nano, except Emacs came first.

Re: The State of Vim

#89
post #7

Earlier quoted context omitted.

With nvim, there has been quite the resurgence of Vim. Good software tends to be resilient. I believe both emacs and vim will see many, many more years.

Neovim feels indeed the proper future-proof evolution of a standard. Its still a bit cumbersome to setup (fonts, lots of plugins to configure, opinionated and overly decorated UI etc.). The acid test of maturity is the dry functionality you get out of the box in a fresh linux. It should be "just right", introducing the new thinking and functionality of neovim without getting in the way.

I actually like `nvim --clean`, which is just the basics. Early on in the Neovim project, a lot of heirloom defaults were changed to be more modern, resulting in a better (IMHO) out-of-the-box experience. I use `nvim --clean` as my man-page viewer:

  MANPAGER=nvim --clean -c "colo sorbet" +Man!
Startup speed is blistering.

My current config is pretty stable, and not that large. But if it were causing issues, I'd seriously consider only doing LSP setup, which is not that onerous with the latest APIs (it was already fairly easy with `vim.lsp.start`, but `vim.lsp.config` and `vim.lsp.enable` make it easier still: https://neovim.io/doc/user/lsp.html).

Re: The State of Vim

#90
post #12

Earlier quoted context omitted.

that'd be the wrong lesson to extend a period of using a bad governance model for longer

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)

> software projects don't need to be democracies

Especially opens source ones, where anyone can spawn their own kingdom via a simple "git clone".

Post reply on HN