Live data from Hacker News

Notes on switching to Helix from Vim

jvns.ca

101–110 of 242 posts

Re: Notes on switching to Helix from Vim

#101
post #7

Helix wants to be Emacs. Ever since they decided to use a built-in Lisp dialect called "Steel" for scripting and become the next Emacs, not the next Neovim, I stopped following it. I love Lisp, I wrote so much code in Lisp in the '80s and early '90s, but that was another millennium! It's 2025 now, and just because it's easy to write Lisp interpreters doesn't mean we should use them. In fact, maybe Forth is even easie…

I'm not sure why you think Lisp is somehow "outdated". It is a perfectly modern programming language and new Lisp code gets written at startups today in 2025.

Re: Notes on switching to Helix from Vim

#102
post #100
post #73

Earlier quoted context omitted.

> 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 Counterpoint: the sequence should only have an opportunity to be "unfinished" if there's actually a choice to make. Showing too many choices at once can be overwhelming and in the Vim environment there are usually a ton of choices. Con…

> if there's actually a choice to make. I don't get it, there is always a choice to make, which is which action to continue with? > Showing too many choices at once can be overwhelming It can't be more overwhelming than having to remember all of those choices and using external docs/configs to look them up! Besides, it's not like there are no improvements possible and you have to show everything at once. For example,…

> I don't get it, there is always a choice to make, which is which action to continue with?

The point is that if the input for a command is XY, there had better also be an XZ. Otherwise XY should just be X.

Re: Notes on switching to Helix from Vim

#103
post #61

I cannot express how liberating it feels to opt out of "advanced" editor tools like lsp. I program in neovim with no plugins, no syntax highlighting and no autocomplete of any kind. There is a discipline that this imposes that I believe leads to better quality programs. It's not for everyone I suppose, but I really recommend trying it.

I recently found out that Mitchell Hashimoto has a setup like this, which blew apart my belief that you need modern tooling to be productive. Do you not find that you fatigue more quickly as a result of having to actively recall everything though? I can't understand how doing things like this would actually result in better code.

Re: Notes on switching to Helix from Vim

#104
post #80

I tried to switch from neovim to helix for a couple weeks, but noted down the following things that were essential to me and not implemented yet: - Code actions on save, for example adding Go imports: https://github.com/helix-editor/helix/pull/6486 - Fuzzy search with a filepicker like telescope+rg, seems to have been added earlier this year: https://github.com/helix-editor/helix/pull/11285 - Automatically updating b…

I have the same issue with Helix not watching and reloading modified files automatically, as I sometimes run external programs modifying those files (templ and sqlc are good examples). Curious about how experienced Helix users are addressing this.

Re: Notes on switching to Helix from Vim

#105
post #95
post #10

Earlier quoted context omitted.

I use kakoune, and don't understand why helix seems to be taking off while kakoune (which predated and inspired helix) remains niche. 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 embracin…

I don't have direct experience with either Helix or Kakoune but after only a few minutes tinkering around, I can see one big reason: In Helix, most of the basic commands seem to be the same as vi. Whereas I understand Kakoune inverts the action/movement paradigm of vi. Maybe that's a more sensible design, I don't know. I didn't check to see whether or not the key bindings were similar but at that point, it's rather m…

Helix inverts the verb-selection paradigm in the same way as Kakoune.

Re: Notes on switching to Helix from Vim

#106
post #100

Earlier quoted context omitted.

> if there's actually a choice to make. I don't get it, there is always a choice to make, which is which action to continue with? > Showing too many choices at once can be overwhelming It can't be more overwhelming than having to remember all of those choices and using external docs/configs to look them up! Besides, it's not like there are no improvements possible and you have to show everything at once. For example,…

> I don't get it, there is always a choice to make, which is which action to continue with? The point is that if the input for a command is XY, there had better also be an XZ. Otherwise XY should just be X.

How is this relevant to the tooltip conversation? If you have XY (without XZ) instead of just X, well, maybe you could simplify, or maybe it still makes sense for you for some reason, whatever, in any case you'd appreciate immediate contextual help if you press X and then forget that Y is the finisher.

Re: Notes on switching to Helix from Vim

#107
I tried both nvim and helix from vscode, and no luck. I feel like I don’t need a lot (syntax highlighting, lsp, goto definitions, file hot reloads, and crucially, a file tree). I can kinda get nvim there, but it falls apart when I can’t just enter and exit the file tree+file viewer with a simple ‘vi or q!’. Maybe I don’t understand quite how to get the config just right, but so far a friendly terminal first code editor seems out of my grasp.

Re: Notes on switching to Helix from Vim

#108
post #48

> crashes: every week or so there’s a segfault and the editor crashes. ... This doesn’t bother me that much though, I can just reopen it. 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” a…

I think you completely missed the context for the configuration issues in vim: I’ve been trying to get a working language server setup (so I can do things like “go to definition”) and getting a setup that feels good in Vim or Neovim just felt like too much work.

It might have been a bit harder in the past, but with recent versions of neovim (>=0.11) it's less than 20 lines of configuration. I have quite a few keybindings to jump back and forth through errors and the default keybidings already include things like renaming, go to definition or listing references.

I'd be more than happy to help you configuring it to your needs.

Re: Notes on switching to Helix from Vim

#109
post #48

> crashes: every week or so there’s a segfault and the editor crashes. ... This doesn’t bother me that much though, I can just reopen it. 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” a…

I've been using Helix daily for about three years, and it has crashed about five times. It is very, very rare for it to SEGFAULT.

Re: Notes on switching to Helix from Vim

#110
post #94

If you're interested in learning Helix, consider doing so from the legendary nic-revs redo of the Helix docs: https://helix-editor.vercel.app/ Significantly more pleasant to look at than the OG docs and he includes some nice tips and tricks, e.g. recipes for efficient editing and keybinds that help mitigate the lack of a built-in terminal.

Thank you for this. I was always baffled by the unreadability of the official docs. For me, at least
Post reply on HN