I miss Vim
leblancfg.com
leblancfg.com
You'd have the exact same situation with various plugins for LSP or whatever (perhaps not the color scheme, but those always existed for vim too).
You're just pining for a time you had less functionality enabled.
As an aside I’m surprised that people struggle with vendor management and config management for neovim. Like are people picking unstable packages, or is their config wired up in a super brittle way? If you’re gonna invest in your own tooling, surely it’s your job to set it up to be stable over $TIMEFRAME ? Speaking as someone who’s used pretty much the same Neovim config for a few years with maybe half a day messing with it since setting it up
It's exhausting fixing broken plugins after an update and wading through the dozens of Lua configuration files to add support for a new language.
I enjoy Neovim's ability to be customized but I very much enjoy the out of the box experience with Helix.
With Helix, it was love at first sight. I like how discoverable its UI is. I prefer the modal approach of Helix where movement goes first, so that I can see over what what and where my action will take place. I like not having to fiddle with plugins. I like the defaults, meaning my config file fits on my screen and there's still vertical space to spare.
(I now make sure that my config works equally well in vim and neovim so I don't have to worry about the odd server with only one vim)
I think it happened when I tried out Mason, too. And it didn't feel like an improvement. So I scrapped my config and started a new one. With Lazy (because that's actually nice), Telescope and a few LSPs I need/want. That's mostly it. You don't have to get much fancier than that. (obviously including some basic vim settings and keymaps, but that's just like in vanilla vim, but in lua)
It does everything I need and nothing more.
Nothing breaks because nothing can break :)
Edit: spelling
Personally I’m a huge fan of Kakoune if you still want something customizable. I say that because it interops beautifully into the rest of the Unix ecosystem, and is extremely easy to extend. The daemon mode makes it easy to use it together with other tools like lf and tig. Building a fuzzy finder is two lines of code.
With Helix you’re kinda stuck if you need something that isn’t supported.
The setup process can be tricky, as you mentioned. My config relies on several external dependencies, particularly for LSP servers. I usually ignore the dependency errors initially unless I know I'll need those specific features – then I'll invest the time to fix them properly.
Installing neovim itself can also be challenging, especially on fixed/point release operating systems. I've found using AppImage to be the most reliable solution in these cases.
I'm curious to hear how others handle this balance between convenience and functionality on remote servers.
My major complaint with Helix, and one that will stop me from using it long term, is the (IMO) insane undo behaviour. It always undoes too much and then I get myself into a mess. There's something about undo checkpoints and being able to manually create one, but I don't feel managing that should be my problem.
I still spend a lot of my time learning, I just am not learning how to use my editor any more. Which isn't to say that I know everything about Vim, just that I know enough that further learning in that area has a pretty low ROI.
Recently I've tried zed. It was very weird. Installing modules is slick and performance is decent most of the time, but it lags sometimes and doesn't play nice with i3. I'm guessing it somehow sucks in all keypresses and only hands them over to i3 when it has exhausted its own checks and stopped lagging, causing rather harsh interruptions in my workflow where I usually hop immediately from the code to browser, shell or whatever to check on we results.
I feel the same way. I am not sure what performance comparisons have been made between the two projects, but I stick with vanilla vim (gVim typically) over vanilla nvim due to the responsiveness.
So I guess this post complaints about the way the author chose to configure nvim.
So, no.
In vim I can just run lf to select a file and then return to vim.
!evince filename.pdf
when editing latex files in nvim after compiling?
And, but that does not defeat your point, :term shoots up a terminal in both under Linux.
Recently I tried to use Emacs on a windows machine, and found that grep-find wouldn't work because it actually depends on an external grep program.
The same with modern context and language and project aware auto-completion, it's not bundled in, and you need external components like LSPs to work.
Asking Emacs to be "batteries included" misses its fundamental nature - it's not a fast-food IDE, it's your own personal kitchen for crafting exactly the development environment you want.
Even starter kits - Doom, Prelude, Spacemacs, etc. - are not really "ready-made" products; they're more like recipe books, where you have the freedom to choose and pick from, but they still don't liberate you from having to learn how to "cook things." They don't "magically" solve things for you.
If tomorrow I wanted to use different rules, applying them dynamically based on some conditions - Emacs provides ways to achieve that.
So yes, for completions specifically, I don't want them to be rigidly embedded in the core of Emacs. I prefer this feature to be an extension. Interestingly, Emacs is so versatile that some extensions are built so well that sometimes you completely forget they are not built-in features or an afterthought; they feel as if the editor was specifically designed to have them.
Over time, when things stabilize, that approach can change. But nvim is still very much a moving target.
Python tries a middle ground. An http server is included, sime crypto libs are as well, but if you need something specialized you can still install alternative modules. That model seems to work well.
There are e.g. Spacemacs and Doom emacs that don't only include batteries, but supercritical nuclear reactors about to explode at any moment. :)
I still stand by everything I wrote in that repo, but these days I'm a very happy NixVim user, with my own little mini NeoVim distro, JeezyVim.[2]
I hate to do the "Nix fixes this" meme, but in this case, it really does fix this particular issue of the NeoVim plugin ecosystem and its constant breaking change update culture being a nightmare for end users.
You can build something that works and pin the dependencies all the way down and have a NeoVim config which will pretty much work forever.
Yes, the initial investment is significant, but for me it's absolutely worth it to be able to provision any machine, any VM, any bare metal server and have my entire NeoVim config completely at the ready with all required dependencies in place.
No idea what are the disadvantages of this approach, but then again my usecases are pretty standard, e.g syntax highlighter, linter, auto-completion.
A daggy but effective trick I started using is using cursor (i.e. a context-aware LLM) to help modify my dotfiles, including neovim configs.
If it messes up, simply git checkout . to go back to what you had before.
But usually an LLM is much faster and more accurate than I am (I'm obviously no pro when it comes to neovim configs). I'm careful to work incrementally - i.e. small changes at a time, and read them carefully to ensure you understand what they're doing - but using an LLM to help modify dotfiles has honestly helped a tonne.
This is the problem.
It's not about Vim vs Neovim as you could mostly likely just run your old Vim configuration in Neovim.
The problem is that you don't understand your own configuration.
The conclusion of the article therefore feels entitled: why shift the blame from your own lack of understanding to the author of plugins that they provide for free?