And thats the thing. Neovim (vim) is about the unix way, use existing tools and use them from vim.
Last time i checked this was not an option in helix, and some very trivil things was impossible, like populating the quickfix (is it a thing n helix?) from a makefile command.
Bottom line is helix is basically a stipped down version on vscode, and wont really succeed without a plugin system (and when/if it lands, its basically just a vscode alternative)
Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).
A comparison going into the differences (and embracing of the unix philosophy by kakoune) by someone who uses both kakoune and helix: https://phaazon.net/blog/more-hindsight-vim-helix-kakoune
Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.
I think the philosophy of delaying the plugin system as long as possible is one of the reasons helix has achieved that.
With Helix I just have to learn selection first, and few different binds compared to vim. With Kakoune, I have to onboard into a more complex ecosystem, in addition to that. A lot of people already have vim/neovim config fatigue so that's not very compelling.
In Vim you can for example do "dap" to delete around a paragraph, but you cannot easily invert it ("pad") because 'p' is too common and is already bound.
You can also easily do the "select first" in Vim by first pressing 'v' to start a visual selection, so I just don't see the point.
> "Using vim/nvim for 20 years". "cba to configure LSPs its too hard". What?
Nowhere did she say that she tried and failed to set these up. Your comment indicates that you read it as her saying that it's too hard to do. Where did that come from?
She said it "felt like too much work" which is A) unrelated to difficulty and is B) something that you can say after you've done the thing, just as legitimately as you can say it before you do the thing.
Being able to recognize that something that works just fine but isn't right, and not being satisfied with that is a skill whose importance is difficult to convey. It is related to the sense people get after a while that gives them an allergy to unnecessary complexity. Complexity is fine if it is required. The zero-step LSP set up procedure for Helix proves that the multi-step LSP set up procedure for vim can be improved.
Back when I explored helix as a long-time vim user, I had some LSPs set up with neovim. But I was very much in doubt how to take advantage of these LSPs and what kind of configuration options make sense. The "hard" part is understanding what LSPs can do for you and what kind of key bindings I need to set up, so that I can use the relevant features.
Helix gives you a sane user interface to LSPs that is discoverable
But some people don’t actually want to find the perfect editor, they would rather stay on the journey forever, trying to master a new tool every few years. Sounds miserable, never knowing true mastery and enlightenment.
For all personal work and just quick text editing I use Helix. If I could use Helix for everything I would
For all the Vim similarity, inverting the do-this-to-that seems like an arbitrary annoyance that I don't understand. Why go from "change this word" (cw) to "I want to change this word, so I'm going to select it first, then change it" (wc). I mean, it's not a big deal, especially if you're not already using Vim, but why THAT of all things? The difference is [explained] but the reasoning behind it is not.
Also the docs mention zero configuration but the first thing I had to do was find out why the LSP wasn't showing any information and then create a config file to fix it because the default behaviour doesn't show anything from the LSP, which makes it seem like it's not even there.
And there's no :help command.
Maybe it's a great editor, but I guess they're not targeting existing Vim users for conversion.
[explained]: https://docs.helix-editor.com/from-vim.html#migrating-from-v...
For me, after trying the Lazy neovim plugin distro and being a long-time vim user, Helix fills a unique need:
- It's beautiful (lots of attention to detail) - It's fast (meaning: at no point did I think Helix is slower than it should) - It's hugely ergonomic (each default keystroke resonates with me and the modal selection is a boon for my brain and productivity) - It requires almost no configuration out-of-the-box
I can't be bothered to use neovim and configure it, and vim doesn't cut it. I need something in the middle between nvim and VS Code, and that's Helix for me. This might have been different had I been a vimscript wizard, which I'm not.
I don't need Helix to be more modular or UNIXy, I simply need it to keep on the direction they've taken. There's a thriving ecosystem of tools around it, and I can use it with Claude Code (by simply refreshing the buffer when there's a new edit). What else can I ask for?
Helix is a great editor, one of the very best I've ever used. As a result, I started chipping in monthly money to keep the project going.
In terms of future improvements, the only one I'm missing the most is the ability to render images or math formulas from the editor, which I hope can at some point be done through a plugin using Kitty's terminal protocol or sixel. This is especially handy when working on Markdown files for notes or blog posts.
Long live Helix.
No matter if VSCode or (neo)vim, needing tens of plugins from almost that many different parties always made me feel quite uneasy.
So, I kind of agree with you, but that’s still a lot of dependencies baked into the editor. It’s probably not as bad as Neovim+plugins, but it’s still a supply chain issue.
You mean Lua wizard (for Neovim).
I think this is catching me off guard. Especially in the past 5 years there are Neovim distributions that make this extremely easy to configure.
I am not disagreeing that many (most?) developers don't want to spend time debugging their editor - they just want it to work batteries included (or a simple button click to install). I think this is why JetBrains products are so popular (I still don't understand VS Code - it's the worst of all worlds between vim/emacs and Jetbrains).
But if you've been a (neo)vim user for 20 years, it sounds very odd that you haven't successfully gotten LSP to work in a way that feels comfortable. I don't want to assume things about the author because I do not know them, but it feels unfair to say for vim and doesn't strike me as honest.
I hope they're happy using helix tho
As a similar example, I could never be bothered to install and configure any LSPs even though I've been using
vim for more than a decade. The friction of doing that was always just a little bit higher than installing a full blown IDE when the work actually requires high level LSP functionality.They can be easier to get started with than just installing Neovim from scratch. But they add their own complexities. First, you have to know that they exist, and pick one. Then you have to know how to configure them, they may have their own nuances about how things are done. Under the hood they're using all the same packages, so you'll need to learn how to configure those as well if you don't want the defaults.
I would say the distributions to make it extremely easy to get started with a functional IDE experience with LSP features. But they're not without their own learning curve.
I also took pause at the claim that LSP was the issue. Neovim + treesitter + LSP feels... fairly solved at this point? It was definitely a bit rough 5 years ago, but it's pretty smoothed out now. Not sure where that opinion is coming from (and it feels at odds with everything else I've read from jvns, to be honest!)
Vim is better of course it’s just hopeless to get people to use it.
There are other things too, like pressing `*` then using `:%s` is no different than the behaviour they describe. I use a plugin that shows you all the updates live as you type making it essentially the same as multiple cursors (for this example). The only difference is that you're typing on the command prompt as opposed to the current line.
For many years I’d mostly been using a GUI version of vim/neovim, so switching to actually using an editor in the terminal was a bit of an adjustment."
For a long time my pain with this was that I often want to open an ephemeral editor while not losing context and sight of my terminal.
With a GUI editor you always get a fresh window, but in the terminal this is difficult.
Luckily
zellij edit
bind-key j command-prompt -p "vim:" "new-window -c '#{pane_current_path}' 'stty -ixon -ixoff && vim %1'; select-pane -T '%1'"
Clearly I've been able to have seperate modes in my mind for "traditional" keybindings, as I don't find myself having difficulty switching from a text field in my browser or chat apps and then going to vim and back, so I wonder if it's just a case of the helix muscle memory needing to be so ingrained, or if it's just in an uncanny-valley to the vim experience.
After 10 years of writting software, i know exactly what i want out of my IDE, so i took up a clean (completely clean) neovim and started building every single functionality by myself exactly as i like it. I call it, jokingly, unlazyvim.
I had been using vim for many years, but finally, after so many years my editor feels like a fine glove. Don't look up my code, don't ask what I built. Go build your own.
Strange approach to data loss, since it doesn't have persistent undo, you can't just reopen it to the same editing state?
> After using Vim/Neovim for 20 years, I’ve tried both “build my own custom configuration from scratch” and “use someone else’s pre-buld configuration system” and even though I love Vim I was excited about having things just work without having to work on my configuration at all.
I don't really get it given how primitive the resulting Helix config is (I mean, even the most frequent commands are based off the mistaken unergonomic w/b defaults), presumably you would've been able to replicate it comletely in the first X years of using vim, and then there is no hell anymore?
> little help popup telling me places I can go. I really appreciate this because I don’t often use the “go to definition” or “go to reference” feature and I often forget the keyboard shortcut.
Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away
I've been using Vim/Neovim for 20 years, but still can't get enough of which-key[1] which I only installed ~6 months ago.
constantcrying•2h ago
Not to take away from Helix, which I think is a cool project. But I think it's greatest strength is that it can (and should) be more than a vim rewrite in Rust. It can actually get rid of the legacy parts of vim and redo the things which did not work and integrate modern features from the beginning.
MyOutfitIsVague•1h ago
ikety•1h ago
Helix is actively inspiring Neovim to become a more comprehensive baseline. Which is freaking awesome. One day the ootb experience will be so good with neovim that few will care for these "zero config" distros.