Yep this reads like someone who tricked out their car, blows out the clutch because it has too much horsepower, then starts pining for the days when they didn’t need a double clutch. You never needed a double clutch!
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
This is what Helix did right - putting essentials into the core. I'm still not sold on their editing model, even as someone new to modal editing and not encumbered by existing habits. The improvement is not that dramatic to justify abandoning the vim keymaps which you have in every editor. Also, it is missing features like debugger or git integration, so I will stick with Neovim for now. I do like, though, that they are choosing Scheme for extension language. That alone may convince me to switch in the future.
I agree. Helix has been the first TUI editor that I have been able to be productive on. With Emacs, vim and neovim, there was so much fiddling just to get started. And the more functionality I added, the slower and bigger the editors became, so I kept going back to the JetBrains suite and vscode.
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.
Helix is amazing and so portable, I switched entirely off graphical ides to it when I started needing to do dev from multiple machines and couldn't keep my files synced on the dev server with any of the graphical ides and after I tried neovim for a couple weeks and found it difficult to maintain. Now I just mosh to the machine > source my venv when necessary > hx
I did the same and don't regret it. My Helix config is 4 lines and it does 95% of what I want. The performance of a ton of neovim plugins is also atrocious and I always hated that everything was a hodgepodge mix of C, vimscript and Lua.
I also fell into the neovim pit of plugin horrors. The good news is, you can get out, empty completely your config (or rather, go back to vim) and start from scratch with only what you need.
(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 felt the same around a couple of years ago. One day my giant and fragile config got broken beyond repair — I was using package manager without version pinning, my fault essentially. After spending a few days trying to figure which versions of 30+ plugins should work together and also use the settings I had in init.lua (many plugins just deprecated their own settings), I realised I don’t ever want to spend time on this. Went full opposite — installed Vim, found my vimrc from pre-Neovim era, removed all the plugins and happily using it since then, just stuff vim has out of the box.
I understand your and OP's situation and I got overwhelmed by all the fancy plugins myself. But then I realized: Hey, I can just use neovim like vanilla vim and don't have to get the next best plugin when it comes out.
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)
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.
I echo the author's feelings, though not for the same reasons. The main reason I want to be comfortable if not proficient in vim - and why I use it as my goto editor - is so that I know my way around when I have to login to remote servers.
But with my neovim setup now relying on Telescope, Ack, and various other plugins, it takes me a minute to get my bearings when I have to work without them on remote servers.
I can totally relate to this. My approach depends on how often I'll be working on the server. For quick, one-off tasks, I stick with the system's plain vim distribution. However, if it's a machine I'll be accessing frequently, I go ahead and set up neovim with my config files.
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.
I've been enjoying my time with Helix, although I've had to undo some muscle memory associated with vim, and add back commands I missed too much (never letting you go, 'dd').
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.
Vanilla vim still exists and still works just fine. It's my daily driver, and I haven't touched my .vimrc in probably 2 years.
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.
I use OG vim mainly because I perceive it as more performant. Maybe my use isn't typical, I don't know, but when I try out nvim every other year or so I usually switch back due to it feeling a bit sluggish. Since version 8 OG vim supposedly has async support, I'm guessing that's why the ALE stuff doesn't seem to lag anymore.
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 use OG vim mainly because I perceive it as more performant.
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.
The point is moot, since you can use your vim config as is, with nvim. I did exactly that, so the only change needed was to actually alias 'vim' to 'nvim' in my bash_profile.
So I guess this post complaints about the way the author chose to configure nvim.
Spot on, this just sounds like complaining for the sake of complaining. Use vim if that's your preference. I used vim for over a decade, and switching to nvim was a breath of fresh air.
While Emacs(I'm speaking of emacs here because that's what I use, but it should apply largely to Vi as well) is very configurable and extensible, I wish something was there that is more "batteries included" than them.
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.
Well, you either have "pre-assembled" hamburger, or freedom to cook your own. Imagine going to McDonalds and asking them to let you into their kitchen to customize your burger from scratch, choose specific ingredients, adjust cooking temperatures, and rearrange their workflow to match your preferences.
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.
That's the unix philosophy of using one tool for one thing, that does it well. The advantage is that it really opens a marketplace which means you are not tied to one solution if that solution turns out to suck. An alternative will quickly pop up, you switch, everybody does that, and in no time the bad piece has been worked around and replaced. This works against the "batteries included" philosophy but avoids being stuck for a long time with sub-par components.
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.
Since I see Helix being mentioned here, I'll start this comment by noting that I am the author of the helix-vim[1] repo which has been shared very widely at this point.
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.
The article centers around vim being easy to configure relative to neovim.
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.
Neovim is 100% backwards compatible with vim, if you miss your old config it still works, OPs problem has zero to do with neovim. You could also just keep using vim.
Use a config distro if confguring your own plugins is too hard for you. Unsure why one would write an 'essay' complaining about having to do some minor coding (terrifying, I know) to use a plugin provided to them free of charge. If it's all too much for you, use VS Code.
[+] [-] riffraff|1 year ago|reply
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.
[+] [-] diatone|1 year ago|reply
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
[+] [-] sudomateo|1 year ago|reply
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.
[+] [-] kombine|1 year ago|reply
[+] [-] agile-gift0262|1 year ago|reply
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.
[+] [-] agieocean|1 year ago|reply
[+] [-] dsff3f3f3f|1 year ago|reply
[+] [-] triyambakam|1 year ago|reply
[+] [-] scarlehoff|1 year ago|reply
(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)
[+] [-] user432678|1 year ago|reply
[+] [-] dailykoder|1 year ago|reply
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)
[+] [-] bhjfjkfgj|1 year ago|reply
It does everything I need and nothing more.
Nothing breaks because nothing can break :)
Edit: spelling
[+] [-] lawn|1 year ago|reply
[+] [-] myaccountonhn|1 year ago|reply
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.
[+] [-] leiserfg|1 year ago|reply
[+] [-] hiyer|1 year ago|reply
[+] [-] drio|1 year ago|reply
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.
[+] [-] klooney|1 year ago|reply
[+] [-] Xiol32|1 year ago|reply
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.
[+] [-] kerkeslager|1 year ago|reply
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.
[+] [-] cess11|1 year ago|reply
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.
[+] [-] GuestHNUser|1 year ago|reply
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.
[+] [-] endorphine|1 year ago|reply
So I guess this post complaints about the way the author chose to configure nvim.
[+] [-] bastardoperator|1 year ago|reply
[+] [-] laktak|1 year ago|reply
So, no.
[+] [-] Zizizizz|1 year ago|reply
[+] [-] billfruit|1 year ago|reply
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.
[+] [-] iLemming|1 year ago|reply
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.
[+] [-] brianstrimp|1 year ago|reply
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.
[+] [-] jampekka|1 year ago|reply
There are e.g. Spacemacs and Doom emacs that don't only include batteries, but supercritical nuclear reactors about to explode at any moment. :)
[+] [-] bsnnkv|1 year ago|reply
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.
[1]: https://github.com/LGUG2Z/helix-vim
[2]: https://github.com/LGUG2Z/JeezyVim
[+] [-] gdgghhhhh|1 year ago|reply
[+] [-] bestouff|1 year ago|reply
[+] [-] nurumaik|1 year ago|reply
[+] [-] anta40|1 year ago|reply
No idea what are the disadvantages of this approach, but then again my usecases are pretty standard, e.g syntax highlighter, linter, auto-completion.
[+] [-] nomilk|1 year ago|reply
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.
[+] [-] vandyswa|1 year ago|reply
https://sources.vsta.org:7100/vim57/index
[+] [-] 63stack|1 year ago|reply
[+] [-] rmrf100|1 year ago|reply
[+] [-] 000ooo000|1 year ago|reply