HN Reader

I've fallen in love with Helix and now use it for everything. Moved from neovim and VS Code to Helix for the majority of my coding.

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.

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 buffers when the files on disk change (claude, templ, sqlc, etc): https://github.com/helix-editor/helix/issues/1125

- File tree in browser, which has been rejected in favor of a plugin system which has not materialized yet: https://github.com/helix-editor/helix/pull/5768

There were a number of other things too, that I could have lived with. I guess I'll try again in a year or two.

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 initially found the noun-verb model of Helix appealing, but I discovered that I prefer verb-noun much better after giving it a try.

One major drawback of the noun-verb approach is its inability to support repetition using the `.` command, which is one of my favorite features in Vim. I often find myself doing something along the lines of `dd..`, `dap..`, `<Ctrl-a>..`, or `/foo<Enter>cgnbar<Esc>...un...`.

More importantly, noun-verb editors have a shortage of usable keys. Too many common operations require the use of the alt key, and that bothers me a lot. This seems inherent to the noun-verb model.

To expand on this, Vim has normal, visual, and insert modes. Noun-verb editors only have visual and insert modes, resulting in fewer options for key assignments. To exacerbate the issue, noun-verb editors have no distinction between motions and text objects. This means they must map text objects in visual mode, whereas Vim only needs to map them after some verbs. So noun-verb editors uses up more keys in less modes.

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.

"using a terminal-based text editor

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

solves this issue nicely for me.

I switched from Neovim to Helix as my primary editor for around a year before switching back to Neovim. The way I'd describe the difference is that Helix is a text/code editor and Neovim is a toolkit to build a text/code editor. Helix is very simple and hits the 'just works' pretty well, but it's development is slow and w/o extensions it isn't flexible enough to handle every situation. Neovim can be a PITA to setup and maintain, but it's flexibility and power are very compelling. It also is semi-mainstream and gets a lot more support... eg. it has the only official, non-vscode, copilot plugin. I still use Helix as my backup editor (when I'm fixing issue with Neovim) and I look forward to it maturing a bit more and for the extension system to land and see where it goes after that.

I tried Helix two years ago, unfortunately the default keymap was a bit frustrating to me. I don't mind changing my habits, however I had difficulty I made sense of the keymap design.

For example, typing `w` select the word. However, typing `2w` select the second word and not two words. To select two words you have to enter in visual mode (`v2w`). To remove two words you thus need to type `v2wd` or `wdwd`. In Vim you can type `d2w`. I miss this composability. In Kakoune (one of the main inspiration of Helix), you can type `2Wd` (`2wd` has the same behavior as Helix).

I was also hoping that the use of Ctrl/Alt modifiers be completely removed. Why not fully embrace modal editing?

> here’s what the vim ripgrep plugin I’ve been using looks like

Fun fact, Vim has built-in integration for grep-like tools via the `:grep` command.

For Neovim, it checks if ripgrep is available and uses it out of the box. For Vim, you can add this to your .vimrc:

    if executable('rg')
      set grepprg=rg\ --vimgrep\ --hidden
    endif

If you don't have ripgrep installed on your system, it'll use plain grep. In that case, the command `:grep -R foo` works just as nicely.

"Helix doesn’t have tabs, instead it has a nice buffer switcher (<space>b) I can use to switch to the buffer I want"

It has tabs if you add (the completely undiscoverably named) bufferline="multiple" to the [editor] section in config.

That bit about search using the ripgrep plugin not providing context has always been available using telescope and a handful of clone plugins.

used vim for ten years now. I have wanted to try this out but stuck in my ways with vim. To me one of the great selling points of vim (I use strictly in terminal, I didnt even know there was a gui) is that no matter what machine I am on, I basically always have my code editor available to me. my .vimrc is about 10 lines, growing at a pace of maybe 1 line a year, and it’s in my head. If I need to switch machines, no big deal, just install my favorite flavor of vim and shell and I’m good to go almost instantly, vs the typical fuss a lot of other editors have to feel “just right.” vim out of the box is really good without much fuss, providing you have got past the learning curve - which admittedly, is steep.

> 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” 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 think what motivated me to try Helix is that 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. After using Vim/Neovim for 20 years...

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.

The best thing to have happened to nvim in recent history is mini.nvim. It's a collection of plugins by echasnovski which satisfies many of your needs in a very consistent, very well documented way.

With nvim 0.12 (nightly) I've switched to vim.pack (built in plugin manager) and the only plugins I had to install are mini.nvim and lspconfig.

The bloat of the neovim distributions are real and what I would suggest for anyone who is a long time vim user is to check out kickstart. https://github.com/nvim-lua/kickstart.nvim , specifically the modular fork https://github.com/dam9000/kickstart-modular.nvim which will give you a great (minimal) starting point

I've tried helix a few times but I've also found it clashes violently with my vim muscle memory, largely because I still use vim in lots of not-vim environments like IdeaVim etc.

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.

I've been trying Helix and really like it. But as someone coming from VS Code, I've been relying a lot on VS Code automatically saving and restoring sessions on restart (things like opened files, unsaved files, cursor position, etc.). It's helpful when I occasionally restart my computer. How do you that in Helix (or for that matter in Neovim)?

As they say, YMMV.

My personal journey:

2010-2014 - sublime text

2014-2017 - vim and later neovim (bunch of plugins to resemble IDE-like experience)

2017-2024 - jetbrains (intellij idea with language plugins mostly)

2024-now - neovim (with lazyvim)

I tried helix in 2023 but it did not stick. Do not remember details but remember the final impressions of having to train muscle memory to “awkward” vim-like key bindings and dealing with various annoyances and bugs. End of trial and error I left it as a terminal $EDITOR for quick and adhoc tasks while doing all the heavylifting in intellij. Ditched it finally when vim muscle memory and hx muscle memory made my brain short circuit several times in a row.

Now I am back to neovim and it is surprisingly as productive (when equipped with proper plugins) as the beefy jetbrains IDEs.

That said, helix looks promising. Maybe it’s the next big thing, who knows)

I really enjoy Helix, but I can't install it everywhere, and so I end up going back and forth between Helix and Vim depending on what machine I'm working on. This puts a lot of pressure on my muscle memory -- I often type a vim keybinding while in Helix or a Helix keybinding while in vim.

Skimmed only. Most titles was like "i use X for that" then scrolled down for the next one.

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)

I switched to Helix a year ago and I’m very happy about it. I used to spend way too much of my free time configuring my editor and now that I can’t do that I use my free time to actually write some code!

I feel like I am not asking THAT MUCH from my neovim setup, but it is so complicated. My collection of vim config is about 1000 lines, that's insane, but when I try to trim it, everything seems required.

My requirements:

- language support (syntax, formatting)

- lsp (I want the goto definition)

- file browser

- quick jump (fzf...)

- a little bit of eye candy, nice fonts and a few icons to make things clear

- auto reload if file changed externally

- splits I can manage with the keyboard

- persistent undo

- in terminal or with excellent SSH remote editing

I would love to have an editor with better defaults. I don't mind learning something good and robust if it will serve me for years.

I recently got into neovim and some things that the author mentions can be found in pre-built configurations like kickstart by default. E.g when hitting "g" I also get a popup with the available follow up keys alongside the final keybind's result. Grepping text provides a preview window with the context of the line that was found

I love Helix. There are some things Julia didn't list that I also miss from nvim, particularly using it as a 3-way diff tool, and missing code folding, but I don't see leaving Helix any time soon.

Was using vim for a decade, discovered Helix, installed it on all my systems and haven't looked back (at least not voluntarily; I'm always bewildered by the old-school CAD-like command-then-subject paradigm when I get thrown into vi on a random machine)

I use :reflow (mapped to =) decently well for wrapping comments, but it doesn't do well at splitting a long single line into multiple lines. My workaround is to add a second empty comment underneath and include it in the selection before hitting =.

Likely fix here, coming soon according to the last comment: https://github.com/helix-editor/helix/pull/11738

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.

Helix still has no way to emulate Sublime's Ctrl + Click (placing multiple carets), nor Sublime's Ctrl + D (duplicating selections and creating a multiple caret for each)?

Funny I just updated my neovim lsp configuration yesterday to get rid of mason and have more control over my tools and found neovim's new vim.lsp.config API really easy to use.

fzf-lua (and several other picker plugins) provide really powerful features and ux out of the box.

I understand that configuration can seem overwhelming but investing a few hours will be really rewarding. I love (neo)vim

"Using vim/nvim for 20 years". "cba to configure LSPs its too hard". What?

Helix is awesome for Go development. Just install go official LSP running `go install golang.org/x/tools/gopls@latest` and Helix automatically handles the rest with sane defaults. Absolutely awesome

Vim is life, no need to change

A year ago I would've loved to see the other way around. Helix is cool but definitely not fit-for-all

too invested in LazyVim.. just learned to use "edgy" with multiple windows: neo-tests, fs browser, diagnostic-trouble, Outline, etc.. and they are just too nice.

The first example of grep-ing source code is not great. It's trivial to install something like Telescope to have functionality similar to the Helix screenshot.

I never managed to understand Vim/Emacs/Vile/Neovim.

Helix seemed all the same until I started watching a series of tutorials on Youtube.

I get better everyday.

I'm on Windows 10 x64 BTW

the percentage of shell scripts that are written in vi as opposed to vim is disproportionate, which is the litmus test for nano and v-studio types

I got tired of the constantly moving space of IDEs and their plugins.

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.

I think it is worth pointing out that there are "zero configuration" vim distributions, which come with the same ease/limits.

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.

The one time I tried Helix, I could find no way to switch from noun-verb syntax to vim's noun-verb syntax, is it possible now?

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 easier than Lisp... well, not really.