NeoVim incorporating Lua as a first class language has allowed plugin authors to build plugins that are faster and better than plugins for Vim written in VimScript (or other languages like python/typescript which are much slower).
There is a strong community for neovim on reddit, youtube, etc and plugin authors do a nice job of building tools that work with each other.
Setting it up I agree is a pain, but once done its very little maintenance/work. Even when I've had to 'redo' my setup (eg switching package managers like vim plug to packer to lazy) its been easy and under 15 or so minutes.
I edit minor things in my config every few months. Everything flows quite nicely now and breaking changes are far less common than they used to be (at least among the plugins I use).
My vim config if you're curious (along with the rest of my dotfiles): https://github.com/sbernheim4/dotfiles/tree/master/vim
Kakoune is OK, but:
Some details of editing are too optimized for counting keystrokes in vim golf, less for thinking-free editing experience.
Configuring and extending text editor with shell scripts is ridiculous.
It's in C++. I want to be able to debug and submit changes to my most used dev tool and I don't want to be touching C++.
Having said that, I still miss the visual-mode-first experience of Kakoune (most moves in Kakoune change/modify selection, while Vim/Helix have visual mode instead).
Otherwise I think Helix already leaped over Kakoune in terms of functionality and polish, because it's just easier to contribute to (in Rust).
BTW. The difference between Vim and Kakoune/Helix is not that big. For basic Vim modes in shells and other tools, I don't really notice it. `hjkl` works all the same.
Kakoune can feel _amazing_ to use at times, but it is at the same time a case study on why brutalist minimalism isn't the best design goal.
I don't doubt there's something, I've just never encountered it.
Couldn't disagree more.
Of course, it is currently necessary for apps themselves to handle splits, tabs, etc, because the windowing systems and terminals are so lacking.
But in an ideal world, the windowing systems would handle all that consistently, and the apps could just focus on their own domain, interacting with the windowing system as necessary.
That being said, Neovim, once you get it set up, is great. The biggest hurdle for me was the config, but if you just start from scratch and make a light config (mines about 200-300 lines, with LSP, hints, etc) you can get through it. And you never have to touch it again, since most likely you configured it in a way you like. Well unless you wanna add the occasional plugin. There are also distros of Neovim that contain a fully baked IDE-lite experience, but honestly those have extremely complicated config, and often IME don't feel nice and light.
It's definitely not for everyone. There is that time investment to get started, but it's definitely been worth it for me.
My config: https://github.com/wrapperup/nvim-config
That was the issue for me, there actually is quite a bit of churn in the Neovim plugins ecosystem compared to VSCode (Packer vs Lazy for plugin management is just the latest iteration). I used to have Neovim plugins all built out but the churn was too much for me.
Small customized config also means smaller and more precise changes. I haven't touched mine in quite a long time, only usually to add that cool trick or plugin that pops up every so often.
I've used vim-plug for over a decade and it's been working fine. Yes there has been a lot of churn within some plugins, but overall it hasn't been that bad in my opinion.
And with lazy tracking plugin versions in a lock file, it's easy enough to pin plugins to a known good version whenever something breaks.
(I finally rewrote my entire config, and lazy is vastly better than vim-plug. I should've done so sooner.)
What's better about it? I ask because I've been using `Plug` since I switched from pathogen (what feels like) an eternity ago and I don't really know any reason to switch because it just sort of works...? Every few years or whatever I'll overhaul the config (not a choice but it just sort of happens) and I'm curious whether switching plugin management plugin has a point.
- You can specify plugins dependencies, instead of having everything in a big list.
- You can separate each plugin setup/configuration into separate files.
- It tracks plugin versions in a lock file that you can commit into git. Makes it easy to identify plugins that breaks and lets you pin it to a known good version.
- Nicer UI to install and update plugins, including a git log for each plugin.
- Lazy loading of plugins. Not critical, but it does make a difference if you have a few slow plugins that you need occasionally or just a lot of plugins.
- Profile plugin startup times in a nice way.
I'm currently using VSCode, but I don't code a lot these days. If you are looking to explore a new paradigm like that, I would go with Emacs as a practical option (with vi bindings) and Acme as a way to open your mind (but not very practical).
IDEs like VSCode and JetBrains seem to be in denial about coding being a text editing activity. Emacs and Neovim want you to take on a part-time job building and maintaining your own personal editor application out of a pile of spare parts. Helix to me is a very promising approach: a text editor that aspires to provide enough polished core features to be a productive coding environment.
Occasionally CoC will ask me to update it, that's running a single command. That's it, as long as you're not constantly looking for new tools and plugins (we've all been there), once you settle on your setup, there is no maintenance whatsoever.
Honestly: I use Jetbrains IDEs now. It is worth having the little integrated tools, like the debugger, etc.
I have a nice NeoVim setup but it gets used less and less now.
I'm sticking with Neovim, especially because I work close to a lot of embedded stuff where being handy with stock vim comes in handy quite frequently.
Also, I don't know what there is to like about Copilot. It fills in code based on what's around it more or less matching intent. It's basically a tool to fill in pieces that someone was going to write anyway, as far as I'm concerned.
What would be ideal for me, but probably not possible in reality, is an editor that cannibalizes popular plugins. So, if a feature is sorely lacking, the plugins appear, but eventually the core functionality grows to replace the plugins. A new user installs the editor and gets a rich set of features that are battle-tested and built to work together. What seems to happen in practice with emacs and Neovim is that the core never gets any bigger, so a new user gets zero benefit from those decades of work, experimentation, and discovery, until they invest the time to integrate dozens of disparate packages into their own setup which they will have to maintain themselves over time.
The other "in practice" side is that without plugins the editor will never get as good as a properly (though painfully, though less painfully with some preconfigured distribution) configured alternative one with plugins
The maintainers are collaborating with the dev and hope to get a PR open sometime this upcoming year.
Vim bindings are not the most consistent, but they are ubiquitous. Every program that offers Vim mode has very similar keymap. If modal text editor deviates from them, it better be for good reason.
Kakoune bindings are very different from Vim, but they are provably and objectively [1] better, so that's fine. They are also more consistent and there is a clear idea behind the whole design. It's written down in documentation. You might prefer Vim or Emacs, but at least you can see that changes from well known Vim scheme are not made at whim.
Helix keymap feels like it was improvised without any thought behind it. „Let's take Kakoune binds and add back visual mode cuz I feel like it.” Currently, they are designed by committee in this GitHub issue[2]. I don't see any design notes and explanations why should I spend time learning Helix keymap.
[1]: https://github.com/mawww/golf [2]: https://github.com/helix-editor/helix/issues/165
A lot of people look at the learning curve and decide it's not worth the time investment, just so they can save time later on when they're more comfortable with it.
But to me it's not about time, it's about how smooth it feels to use, how I can translate thinking to typing/editing with the least friction possible, and nvim with my minimal set of plugins that I curated over years, that is it.
Vim:
+ ecosystem is nice. Plugins and matching keybinds in ACE/codemirror/whatever was cool for interop
+ having vi or vim on any Linux box is nice
- you have to have plugins for basic things like pcre, correct colors (csapprox), and ale
- at least when I stopped using vim, the multiple cursors plugin was nothing near as good as the other two. It was tacked on to a single-cursor editor, and you can tell
+ felt completely natural coming from vim. If you use vim and don't want to warp your brain with new keybinds, try hx. It feels like vim+more. Kak feels like a different editor
+ many built-in features that require plugins in vim/kak
+ using LSP motions felt amazing
+ written in rust, which I love. The codebase is entirely readable and I contributed a patch after only about an hour first looking at it
- hx didn't have motions for ()/<>/... Which I've come to rely on. Kak has m which is like Vim's f(v% if f was multiline
- no advanced keybinds/bindsym in vim/map in kak. Config was toml so the most you could do was bind single chars to other single chars
- no plugin support, though I found myself not really longing for any plugins because so much comes by default
- occasional crashes due to off-by-one errors and .unwraps sprinkled around
+ editing feels amazing. Like the text is directly connected to your brain. This is because basically every action gives you feedback. For example, in vim, t(dt) gives you a cursor move and then the text is gone. t(v%d gives you feedback but takes way more keys, but in kak, md immediately selects the entire bracket after m and deletes it after d. Having visual feedback *as a requirement* (not an option like Vim's visual mode) is amazing. I didn't use hx enough to know if it feels like vim or kak in this regard
+ plugins exist. Kak-lsp is nice. Scripting your own keybinds feels more natural because the scripting language *is* the keybinds, contrary to vim. Basically imagine every keybind is like Vim's but with a :normal before it
+ multisel feels compltetly natural. Not like an extension to what you're doing, but everything is multisel, and you just happen to have n=1 selection sometimes
+/- piping to external programs feels very natural. I have numerous scripts that take stdin and write to stout. In kak, I select whatever I want and just run |encode-url<ret> and it pipes every individual selection to my command and replaces them with my output. This is also bad because if I have 100 selections (not uncommon), it will spawn 100 shells to spawn my command 100 times
- people keep saying it doesnt have a scripting language, which is misleading IMO. There are try blocks, %{} groups, and commands that you need to learn about. Look at hx if you're interesting in no scripting language. It reads a toml config file and that's it.
- a little overreliance on shell. I don't even know if windows can run kak because it uses shell so much. On one hand it's nice because I know Shell. On the other hand, interop feels weird. You echo commands and kak reads your stdout and evaluates it. It's clever and cool, but something about it feels weird.
- keybinds don't behavibe like vim or hx. You have to retrain your muscle memory, but IMO it's worth it. Using vim now though is painful