Hacker News Reader

Comment by imjonse | Hacker News Reader

The ecosystem of vim package managers and plugins is even more diverse and dynamic and hence confusing than the JS frontend one. The more things get built-in (like LSP in neovim) the better. This is the reason there are distributions of vim (Astro, NVChad, Lunar, Lazy) which are convenient for quickly starting but are extra layers or complexity and a source of issues and time wasted.

View on HN

> The more things get built-in (like LSP in neovim) the better.

Since someone inevitably mentions Helix on the *vim threads (and vice versa), I'll be that person today.

This is one of the things I think Helix gets right. It has the LSP, fuzzy finder, and a few other modern tablestakes features built-in, which makes it a joy to use. I spent a decade+ using (Neo)vim, and went from a few hundred lines of homegrown vimrc to maybe 6 or 7 lines of Helix config, for a few bits of muscle memory I couldn't shake.

How much effort was switching to the different keybindings Helix uses?

Not the OP, but surprisingly it didn’t take long. I just worked through the helix-tutor and was good to go in a few hours. Helix isn’t simply an alternative set of keybindings—it’s a different way of thinking about selections and actions. Once that thinking becomes intuitive, Helix’s keybindings just come naturally.

Same as sxg, it was surprisingly easy. Maybe a day or two of fumbling around before I got into the usual flow with it.

I still use vi mode for bash, and occasionally use Vim on systems without Helix. I definitely stumble a bit now, but it seems possible to retain muscle memory for both without much effort.

I mainly use Evil mode on Emacs, but have switched to use Helix for when I need a terminal editor.

It feels like the majority of Helix keybindings are the same as vim. Similar to how with vi-emulators, you'll bump into things you use that the emulator doesn't have; with Helix, you'll bump into keybindings you expect, which are different in Helix. https://gist.github.com/rgoulter/af83932a45c79f9f3fb673d8813...

The impression I get is that Helix's keybindings are well thought out. e.g. u/U for undo/redo vs vim's u/C-r. e.g. rather than Vim's H/M/L, Helix uses "go top"/"go centre"/"go bottom" (gt/gc/gb); and the bindings which jump the cursor around all use this `g` prefix.

Switching back and forth between Vim and Helix, there'll still be false-friends from time to time.

Just checked the script and indeed, compared to the youtube video of 10 months ago, the kickstart script now uses 'lazy' instead of 'packer' as a package manager.

LazyVim the distro is different from lazy.nvim the package manager. Both are written by folke and are excellent. Not sure why parent comment says these are extra layers of complexity. LazyVim is written in a way you can selectively disable or enable the plug-ins it uses. I can't imagine why 80% of these plug-ins would ever make their way into neovim core.

I say they are complexity because first there are a lot of ways to configure nvim by using any of the distros and starting kits and then they are slightly incompatible and use different versions of package managers, fuzzy finders, autocompleters etc. I agree most need not be in core, but it would be better to have fewer plugins doing more or less the same thing and having to find the ones that are less buggy and are being maintained. To be fair this was an issue with vim too, it's not nvim specific.

Astro is honestly the best, instantly converted to neovim.

Reply on news.ycombinator.com