Notes on switching to Helix from Vim | Hacker News Reader

Notes on switching to Helix from Vim

jvns.ca

337 pointschmaynard236 comments

> 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

> 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.

1: https://github.com/folke/which-key.nvim

mini.clue is another good option for this feature in neovim.

https://github.com/nvim-mini/mini.clue

The mini set of modules are such a treasure, Evgeni is amazing.

Yeah, that's the mortal sin of vim - insisting on shitty unergonomic defaults, requiring every new user waste time recreating a better UI while suffering for years before even the appropriate knowledge is acquired

I have not seen any unergonomic defaults in vim. Check your understanding of vim philosophy probably.

Check your understanding of ergonomics if you fail to see the obvious

Can you give at least a few examples? I have no understanding of ergonomics it seems

There literally is a plugin [1] containing sensible defaults that everyone in the community agrees would be good as default but “backspace” and “incsearch” are the most obvious. “Backspace” allows you to delete with the backspace key beyond the point where you pressed “insert”. I don’t think I’ve ever met someone who thinks the vim default (not allowing this) is ergonomic.

[1] https://github.com/tpope/vim-sensible

I wouldn't argue that the vim default (of not allowing backspace beyond where you entered insert mode) is ergonomic, but I do prefer and exclusively use the default vim behavior. It's just what I'm used to at this point (24 years using vim/nvim) and if I set it the "ergonomic" way, it's disorienting.

So, ergonomic or not, some people do prefer the default -- at least one person :).

Have these already been adopted in neovim by default? It seems like I already have this behavior without needing any plugins.

There are quite a lot of default changes so go :he nvim-defaults to get them all but yes, the default setup in neovim is much more sane.

You can start with the original example 4 comments above and try to understand how unergonomic the default way of learning/remembering hundreds of key combinations in vim is.

Then think about the basics: why some of the most frequently used commands w/b are located so inconveniently and far away from each other (and if you reconfigure them, how unergonomic the config language is where instead of reading a sensible name like 'move_prev_word_start' you can only reference 'b' that you'd never use since, well, you've changed it to something else!)

You don't need hundred of commands to use vim, have you at least finished vimtutor? Finish it in the way it proposes, then start it again and think on your own, what commands for more effective passing the problems from vimtutor might have been there as well.

Letters w and b may be located wherever they are located, if you can not touchtype vim is not for you for the same reason we do not learn how to run before we master how to walk.

vi (the name) is ergonomical because of shortness (just two letters).

vi (the editor) is ergonomical because I use to touchtype and vi lets me to never put the hands out of the keyboard (typically its 3 rows but vi made me to learn the 4th row with digits).

vi (the system of text moving commands) is ergonomical because it has all what might be needed right from default.

I recommend you to start exploring vi from the following 4 commands to understand at least what kind of operations can be possible - w, b, e, ge. I promise there are some ergonomics in having all the 4 ways of one word iterating problem. After understanding what did I mean you are free to see some logic in _any_ vim command. (hint - pairness, there are almost no command without at least one complement pair).

Also there is a thing called "UNIX way" (all sayings about how one thing has to do only one task) and damn, vi clones are one of the most ergonomic programs on my PC. After mastering touchtyping using keyboard gives me pleasure, after mastering vi motions doing text editing gives me pleasure as well. Achievability of this kind of pleasure is what I call ergonomics.

GUI editors with modal windows and stealing-focus popups have too much power to destroy my pleasure from the dialogue with the keyboard.

> w, b, e, ge. I promise there are some ergonomics in having all the 4 ways of one word iterating problem.

Again, how can you promise anything if you're ergonomically blind? Take you w/b pair - this is just a dumb binding, these are two of the most frequently used commands in vim, yet they are not positioned in the most convenient location (hint: home row). The Word/Backword menmonic isn't paired (that would be forward/backward), but more importantly, it makes as much sense as binding cursor keys to Left/Up/Down/Right So it fails your own "pairness" criterion in its most basic movement!

> Achievability of this kind of pleasure is what I call ergonomics.

Of course you have your own personalized definition! Why would you use that in a conversation with others, though, when they're more likely using a more common one?

> there is a thing called "UNIX way"

it doesn't do its one thing "well", so as expected, you can't paper unergonomics over with some "philosophy"!

Your complain about w/b not laying on home row is just wrong, for example I do not use QWERTY at all and for me even h/j/k/l are not on the howe row and I still consider these commands ergonomical. Why? Because I use to touchtype.

> The Word/Backword menmonic isn't paired (that would be forward/backward)

What is paired is not a mnemonic but an action. If you start to understand that any command has a complementary command it makes your expectation from vi predictable. It happens in the following way: you learn how to do some moving you are needed, then you check the complementary action (there are 3 layers of complementarity in the word iteration problem: forward/backward, cursor on start/end and word/WORD), then you just make your muscle memory to learn what you saw, that's all!

> but more importantly, it makes as much sense as binding cursor keys to Left/Up/Down/Right So it fails your own "pairness" criterion in its most basic movement!

My thesis is that if the editor can move the cursor left then it must have an ability to move it right (and vice versa), if the editor can move the cursor upwards, then it must have an ability to move it downwards (and vice versa), nothing more. You are talking about some very specific ways to move cursor (there are plenty of them in vim to be honest) and BTW if you are comfortable with cursor keys, so why have you complained about w/b which are not laying on the home row? The home row story is about your hands laying on the keys with letters and controlling all 4 rows, not about your right hand laying on 4 keys and your left hand can not control anything except esc/meta/alt/ctrl/shift.

> Of course you have your own personalized definition! Why would you use that in a conversation with others, though, when they're more likely using a more common one?

Ergonomy is the Psychiatry domain, BTW we are not discussing ergonomic per se. We are discussion about achieving erconomic with only having some well-known instruments: keyboard, console software, display. Of course your definition of ergonomic (which you did not worked to write down here) is about wearing a hat which just reads your thoughts and outputs the correct result, but I tell you about some ways of achieving ergonomics on the hardware you obviously have, I don't tell about dreams of perfect world.

> it doesn't do its one thing "well", so as expected, you can't paper unergonomics over with some "philosophy"!

I promise I do not lie, I am teaching some people offline to touchtype and to use vi(m), but I can not teach you if you don't even ask questions. I write this comment because I work on a book about vi for noobs and I will never get tired to introduce people to see some ergonomics in the things I love which seems obscure to them. For example, if you didn't fire a single bullet you will never see what firearm products are ergonomic and what are not. If you didn't fire a single bullet towards the real enemy you can consider AR (full of bells and whistles) as ergonomical, while in reality what is ergonomical is AK (doesn't jam under the rain, doesn't afraid of the mud, allows to fire knippels against the drones instead of regular bullets). If you have never danced Salsa, you will never understand how the lead is leading and why the follower follows.

PS. Sorry for my bad English, this is not my native language and I am too lazy to polish my grammar with some modern tools. Sometimes I might misunderstand you or write down not what I really think.

I personally like Neovim's defaults since it fixes a few rough spots in old school Vim defaults.

Bonus is once you get used to defaults, almost every server has a Vi installed whose basic features you can use.

> 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. Consider for example if I input `n10` in editing mode; that could be followed by all kinds of repeatable actions and it could be followed by another digit of the count.

> 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, all your "all kinds of repetable actions" can be limited by the most frequently used 10 actions and an "others" submenu you could invoke separately if you were looking for something else. And your "another digit" is just a single line "0-9 continue the count", so what's the issue there?

> 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.

Because if the command is just X then you just input X and the action occurs. There is no need for "immediate contextual help" because there is no time wasted on a useless immediate context.

It's bad UI design to have the user input X and then wait for Y before doing anything when there is only one intention the user could actually have in mind. Having a popup say in effect "hey, I'm not going to do anything until you press Y" is not an improvement.

> input X and then wait for Y before doing anything when there is only one intention the user could actually have in mind

That's obviously false, the second possible intention is... cancellation. For example, you can bind Q,Q to quit the app (and no other key is prefixed with a Q), but then you could press Q mistakenly or change your mind at the last moment.

But you continue to argue with your own strawman - nothing about helpful popups changes the underlying behavior. So if your magic design is to run XY just on X press, that would be bad design, but you can still do it! And the popup will never appear because the action is complete, so no help needed.

You’re going to hate that my shortcut for Normal mode is j-k, and I don’t have any other j-* commands.

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.

FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase.

I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significantly jankier than just opening the damn .sln file in Visual Studio.

Once I did all that it was, as you say, very little actual stuff written in my .spacemacs. And probably could have been less if I had felt like figuring out how to get my windows emacs to find clangd on the path instead of giving up and just specifying full paths to everything.

I only persevered because emacs (unlike Visual Studio) gives you all the necessary access to its internals to build LLM Tools around its LSP functionality.

Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt on save. So yeah, nothing I'd wish different from it.

Edit: upon further thought, I don't like having to move my hand to the arrow keys to select from the auto complete list, even if there is only one thing and then hit enter, rather than hitting tab to pick whatever is left.

> upon further thought, I don't like having to move my hand to the arrow keys

ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.

    > I had to get my project to emit compile_commands.json,
    > get clangd, figure out which things about our build
    > process clangd was not understanding from 
    > compile_commands.json and add them in .clangd

That sounds rough. This is anecdotal, but in my Linux corner of the world, ccls has been an easier user experience as a C and C++ LSP since I've never had to resort to messing with flags in the generated file.

I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.

By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.

The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:

    vim.lsp.config('ccls', {
        init_options = {
            compilationDatabaseDirectory = 'build',
        },
    })
    vim.lsp.enable('ccls')

My actual config does also contain a capabilities = ... argument that forwards the default_capabilities() from nvim-cmp, but you get the point. I hope that helps in case you're curious to give neovim another spin.

I did actually try CCLS first, but this was several years ago so it's possible that it may work better (something about our codebase was causing it to crash) - I should try it again.

Lacking LSP didn't stop me from using spacemacs, though. Oh, no. emacs has an auto-complete mode that just chooses from a pool of symbols already present in open files and that turns out to be Good Enough for me to prefer editing code there vs Visual Studio, IntelliSense be damned.

My employer furnished me with a beefy enough workstation that I can have Visual Studio open (to semantic search the whole codebase for stuff I don't already known where to find and to build/run/debug) alongside emacs (for editing and general code browsing when I know where definitions live).

This. Now that LSPs are natively understood by neovim it's a very painless process. Especially if using mason to fetch the language servers.

Getting LSP to work on recent versions of Neovim is one plugin + one line of configuration. Here are the steps for enabling clangd:

1. Install nvim-lspconfig plugin

2. Add `vim.lsp.enable("clangd")` to init.lua

You can even enable LSPs on a per-project basis by taking advantage of the revamped exrc feature:

1. Add `vim.opt.exrc = true` to init.lua

2. Add `vim.lsp.enable("clangd")` to $projectdir/.nvim.lua

You don't even need the plugin nowadays, you can just go to the lspconfig repo and copy paste the default config if you don't know where to start. lspconfig was an incredible effort, and I consider it a good thing that it is now fading into a simple repository of default configurations.

I'd say that having a plugin with default configurations that is kept updated is a necessity. Because that's what enables me to use LSPs with a single line configuration.

Serious question: how often does a sensible default configuration need to change? I think I have used the same jedi-language-server config across projects and computers since before Neovim had a built-in LSP client, with the only changes being on the Neovim side gradually migrating to new features as they appeared.

Obviously do whatever works for you. But I do feel like most LSPs shouldn't need more than a few lines that you set and forget.

Well, LSPs come and go so that's one source of churn.

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.

> every week or so there’s a segfault and the editor crashes.

The author of the OP appears to have edited it to indicate that it's just crashing, and doesn't know if it's a segfault or just a panic. It appears there is some known potential for segfaults in tree-sitter, which is a native C dependency.

I have had treesitter crashes in the past editing markdown, causing helix to segfault, but the particular bug that caused my crashes has been fixed since years.

> presumably you would've been able to replicate it completely in the first X years of using vim, and then there is no hell anymore?

I agree with this, but being able to ssh into a server and just grab Helix instead of copying over my Vim config and whatever else it depends on is really nice. Makes your dev env feel a lot more portable (although also more barebones than a crazy Vim config)

It's not like Helix is as ubiquitous as Vim on a random remote server. If that's not the case surely the effort to install Helix is bigger than copying Vim config?

I've had trouble in the past with systems whose version of vim is too old to understand the options in my config.

How is so? I have my dot files in GitHub. I just have to clone, run `PlugInstall` and it's all ready.

Glad it works for you! My dot files are in a private repo, I don't want to bother with adding new SSH keys to my GitHub account and then remembering to cleanup everything for what could be a one-time use. `apk add helix` is way easier for me.

this was my plan, but then i got really into using LSPs and i'm not about to install every LSP on every server i ssh into.

Currently i just use sshfs to mount whatever directory i want to work on locally, nice to have all lsps available and also see my changes reflected on the server instantly.

>> 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.

I agree 100%. This would be helpful in so many places. That was my favorite part of the article -- one little paragraph and screenshot, but it made me desperately crave that feature almost everywhere. I agree that it'd need to be smart about it -- after a timeout, as you mentioned, is a great idea. That way it can stay out of your way if you know what you're doing, and only pop up when you hesitate.

Neovim with lazy.nvim has that by default (delay included).

I'm not Neovim person, but would you happen to know what plugin provides that feature?

Sorry I'm exhausted and lazy.nvim is the package manager, but I meant lazyvim which is the distribution. Within this distribution I'm pretty sure it's which-key that provides a popup. If I type <leader> it pops with suggestion (and a little icon in front of each indicating if the next key has sub-commands or not).

folke/which-key.nvim: https://github.com/folke/which-key.nvim :

> Customizable Layouts: choose from classic, modern, and helix presets or customize the window.

LazyVim keymaps: https://www.lazyvim.org/keymaps

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.

All of this plus that with their approach of shipping an editor that is useable out of the box I feel a lot safer from supply chain attacks.

No matter if VSCode or (neo)vim, needing tens of plugins from almost that many different parties always made me feel quite uneasy.

Their cargo.lock file is 3500 lines or so: https://github.com/helix-editor/helix/blob/master/Cargo.lock

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.

it's 317 unique crates, some of which are internal

  305 with helix- removed
  258 with gix removed (git stuff in multiple packages from a single upstream group)
  240 with windows api wrappers removed.
  170 if you remove all subprojects (split on -/_ taking first field, then uniq).

what's left?

  fast math and various hashes
  backtrace utils
  various build utils
  some allocators, zero copy facilities, mmap and structures   like lrus
  time and date handling
  character maps / internationalization
  concurrency libraries (futures, runtime, etc)
  cross platform path & directory helpers
  support for general unix platforms, for redox, for linux, for windows
  logging infrastructure
  some compression libraries
  markdown
  various testing helpers
  rope string representation
  shell lexer and utils
  terminal interaction models
  toml
  wasm & wasi

compared to neovim, which is hard to determine because c & cmake toolchains are a bit of a shitshow to figure out, but lets take a look at maybe debian, that says 34 package dependencies downstream. The list is clearly missing a bunch of the toolchain, has limited portability and so on, but certainly shorter at 34 - for a single platform. Note also that neovim bundles several dependencies (e.g. markdown and so on - so they're "hidden" (almost surprising debian hasn't done their usual trick of insisting this isn't hidden))

so where's the rest? well the rest is in the project: tokei says helix contains 132kloc. tokei says neovim contains 984kloc.

so round a little and you get: helix has an order of magnitude more dependencies, but also an order of magnitude less code than neovim.

while I'm sympathetic to concerns around dependency bloat, particularly with an eye to the js ecosystem and supply chain security, it's important to look through the right lens - when the functionality is fairly closely equivalent (there are differences, helix has a lot more modern features, vim has a lot more traditional text manipulation and unixy integration features), and there's an order of magnitude tradeoff in both directions - this is likely demonstration of fairly effective code sharing in helix.

there are important supply chain safety techniques required when using a wide number of disparately owned dependencies. there are also important supply chain safety techniques required when managing a wide number of disparately owned sub-directories of a larger project. there could just as well be a needle in neovims vimscript haystack as there is in helix dependency stack, i can tell you now though, as i'm familiar with almost all of helix dependencies i've put eyes over their code at least once, there's almost certainly been more eyes on helix deps recently than on neovims vimscript - though eye's passing over don't always catch things either of course.

But once helix adds plugins it will be exactly the same because those tens of VSCode plugins provide functionality not present in helix, so will be similarly implemented externally

I hope they will properly sandbox plugins like any modern software should.

That would've been the wasm plugin route, which was rejected in favor of this great emacs feature of using an obscure language, so sandbox are unlikely

> This might have been different had I been a vimscript wizard, which I'm not.

You mean Lua wizard (for Neovim).

At least lua is a real language, i.e. a language used by more than just vim.

If you need something between nvim and vscode what's the issue with using vscode with vim plugin?

I enjoy helix but don’t write nvim off entirely. I’m not much of a lua dev but llms have proven themselves to be excellent when writing and modifying nvim configs.

IMO that was the biggest motivator to switch was helix’s well put together lsp/lint config.

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 rebuild from HEAD using homebrew quite regularly and have maybe had a single crash in years using Helix, so I'm shocked to see Julia report she's had crashes. But because I run HEAD, I can tell you what's actually merged which might not be released yet:

> Code actions on save

There are command on save hooks which solve the problem for Go, but I could see this being not as applicable for other languages.

> Fuzzy search

Man, I'm pretty sure this shipped before telescope was particular stable or popular. Although, I don't recall if Helix originally used the ripgrep backend at first. They reworked it earlier this year and it was a massive improvement.

> Automatically updating buffers

+1 to this. I constantly suspend (ctrl+z) my editor and sometimes forget about it and could really use this prompt.

> File tree in browser

Space+e or Space+E opens a hierarchical file explorer on HEAD, but this is definitely relatively new

> I tried to switch from neovim to helix for a couple weeks

I bounced off after a couple of hours because 35 years of muscle memory for vim commands meant I was making constant infuriating mistakes[0]. Which is a shame because I'd really like to use helix and avoid the neovim config faff.

[0] I did try one of the "vim keybindings for helix" but they were only partially correct and that annoyed me even more.

Although the file explorer you link there was abandoned, a vim-telescope style explorer was merged earlier this year.

However, when you already have a fuzzy-search based file picker built in, an explorer doesn't bring much extra utility.

Totally disagree. I find having both extremely useful. Once I start to get to know a code base jumping through files with telescope is super useful. But when I'm getting spun up on a project and don't know what files I'm looking for, a file tree is super nice.

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.

I have file reload binded to key:

    [keys.normal.space.f]
    f = "file_picker_in_current_directory"
    F = "file_picker"
    b = "file_picker_in_current_buffer_directory"
    "." = ":toggle-option file-picker.git-ignore"
    g = "global_search"
    e = "file_explorer"
    r = ":reload-all"
    x = ":reset-diff-change"
    w = ":echo %sh{git blame -L %{cursor_line},+1 %{buffer_name}}"

> 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.

That is surprising. I didn't have much trouble getting LSP working either in og or neovim. My editor config is fairly barebones by preference, so its not like I spend a lot of time editing my configs either. I will say, Lua is a lot more ergonimic than vimscript for a lot of things, but I appreciate that I can still use the old ways at times. Like ALE isn't leaving my config unless I'm forced to remove it for some reason.

I hope they're happy using helix tho

I use a plugin[0] for LSP in vim and it's pretty easy to setup there too. Installing and configuring the lsp software itself take more time as I'm constantly moving between OS.

Also, Emacs and Vim is very much about making the tool your own. I don't mind shaving the yak every now and then, because once an inconvenience is solved, it stay solved.

[0]: https://github.com/prabirshrestha/vim-lsp

I've never used a distribution and LSPs are in my opinion easy to setup in Neovim and especially now with vim.lsp[0].

[0]: https://neovim.io/doc/user/lsp.html

I'm not sure your implication of LSPs existing, specifically for vim, or in general, for 20 years is actually true in order that your questioning of Julia's skills to actually make sense.

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.

ar_lan specifically mentioned Neovim distributions. Examples would be LazyVim and AstroNvim. These are packages you can install that provide Neovim in a pre-configured and opinionated way. They generally come with language servers, linting, and various other features out of the box, and have their own paradigms for configuration.

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.

The problem is that I must make these distributions fit within my well established configuration, which is not as easy as installing them on top of a blank one.

Also it might be the fact that vim was never my main programming tool when IDEs were available for the programming task at hand. I debug as much as I write code, so having the debugger in the same context is important to me.

These things may all sound like excuses, but what I'm trying to convey is that vim can be a tool with which someone is proficient, but it's not the main one for writing code, and as soon as friction gets higher, it gets disregarded in favour of something else.

I think you're using asterisk, maybe *vim, and it's italicizing your text until the next *vim. You'd have to escape it with backslash.

I'm trying to be careful to distinguish that this particular part seems odd to me, specifically because of Julia's other posts in which it seems their skill/knowledge is not much of a question.

If someone is new to vim, I 100% agree that it's easier to get started with VSCode/Jetbrains/etc.

But if someone has been using vim for a long time as their default editor, especially Neovim, and when LSP support came to Neovim about 4 years ago [0], it comes across as someone who isn't a power user if they didn't end up installing it. Which is fine, but the community has also started to build reasonable "batteries-included" distributions of Neovim (LunarVim is a great example) if someone didn't want to figure it out themselves but still wanted to use it.

It's one thing if someone just doesn't love the experience Neovim brings to them. That's reasonable, because it's subjective. But it is odd to use a tool for so long and not further investigate what it offers to fit your needs. Before LSP, there were libraries (CoC for example). And if it was never satisfactory, why not look at alternative editors which had their own flavors of indexing/code navigation?

[0]: (https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...)

I've noticed a number of moderately sized companies "standardizing" on vscode tooling. You can use other editors, but they'll have extra special support for vscode: default project format settings or special tooling for debug integration specifically in the form of vscode config, that sort of thing. Recommended plugin sets.

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!)

When I worked with programming students we used VScode despite me, the professor, and most of the other grad students not liking it. It’s just so easy to download, has the “run” button, and, well, at least it isn’t Eclipse I guess.

Vim is better of course it’s just hopeless to get people to use it.

I think with Cursor choosing it as well, this will only continue to prevail. Professionally I've had to standardize on VSCode due to Cursor (there are a few plugins for Neovim but the experience is undoubtedly better in the first-class tool).

By the way - I actually generally think this is a good thing that companies standardize on something. I might not like the choice they standardize on, but the barrier to entry for new engineers is already high, so having an easy-to-use and familiar development setup that "just works" from the start is pretty reasonable for large companies.

Totally weird. LSP has been a neovim builtin for how long now? Two years?

4 years. https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...

Also been doing vim and now neovim for 20+ years. LSP just broke and several keybinds alongside it and just not looking forward to figuring out what happened (but will anyway). It's a huge mental block for me whenever I need to get into configuration. So to me this feels very relatable.

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.

Verb-noun changes how you think too. I believe it’s more in line with the mentality required to write code.

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.

Most people optimize for productivity and not raw quality of code. I can't imagine that your productivity is higher for removing autocomplete.

I'm not saying you need every plugin ever, but autocomplete?

Maybe you haven't tried "advanced" editors in a while, and it was a lot worse last time you tried?

I had a few periods of doing the same in sublime text, I did use syntax highlighting though. It’s a really great feeling and very liberating, especially in a greenfield project.

Can’t really justify it at work though, projects are too big to and gnarly keep in my head.

Why neovim for this? Why not nvi? Even less distractions that way!

I can see no plugins, I can even see no autocomplete but no syntax highlighting is just making things difficult for the sake of it

The true Plan9 aesthetic

To each their own. I quit using syntax highlighting about 10 years ago and won't ever go back (been programming for 25 years, vim/neovim user for 24 years). I just like it better, it works for me. It definitely does not make things "difficult for the sake of it" (for me). There are dozens of us! :)

(As to the rest: I use a pretty minimal set of plugins and I use the built in nvim C-o/C-p or C-x C-o/p "dumb" autocomplete. At least I think it's built in...)

How is no syntax highlighting better, specifically?

Not op, but in my case a lifetime of colourblindness has desensitised me to colour as an indicator.

I have my editor configured with zero highlighting for keywords and syntactic elements. Admittedly, I have compilation/lint/syntax/type check errors set to invert the erroneous block, black background white text.

Syntax and keyword highlighting is just noise given I’ve been trained by decades of colourblind unfriendly interfaces

that's a very good reason to not use syntax highlighting. If that is what the other guys are dealing with, I withdraw my critique but I don't get the impression that is the case

Syntax highlighting doesn't necessarily mean color, though. Using boldface to highlight keywords is another option that is traditional in some circles (e.g. Delphi has been doing that for 30 years now).

(To address sibling comment: If I were colorblind, I would lead with that in any conversation about syntax highlighting; I am not colorblind.)

To answer the question: it's a feeling, like lots of things in software development. I tried "no syntax highlighting", found that I liked it, and I no longer use syntax highlighting. To say "specifically" how it's "better"... I'm not even saying it's better. "I like no-syntax-highlighting" is the statement I'm making (which, when it comes to syntax highlighting, is a statement a lot of people have issues with). So, from my personal experience, I take issue with the statement that no-syntax-highlighting is making things "difficult for the sake of it".

Try this out for analogy: I ate Red Baron pizzas every Friday night for 15 years, then I heard about homemade pizza 10 years ago. I tried making homemade pizza. It was good! ("I tried it and liked it") Now I only eat homemade pizza on Fridays. How is homemade pizza specifically better? It's better because I like it more. That's all there is to it. It's a preference.

(For the analogy to work, you have to like or at some point have liked Red Baron frozen pizzas. I happen to like them... the analogy is flawed though, I admit!)

(Let me preempt criticism that I'm comparing Red Baron frozen pizzas to syntax highlighting. I am not. It's only about the preference, not the object of the preference.)

You kinda get used to it. I often `cat` and `less` code in the terminal and my $EDITOR is `mg`. I know about bat, but it's never in base.

And I'm using more my mental idea of the code and direct line:column navigation. My context is often less than 10 lines of code.

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.

Not GP, but I can add my two cents.

The trick is to avoid idle browsing of the code. Be intentional about what you need to do.

I use tools like grep/ripgrep to get a more focused of the code. Then with the line number, I can jump directly to where I need to be. Same with tools like linters and compilers.

In the same file, I often use search instead of line/character movement. You search for a symbols and you just cycle through their location.

I don't think it leads to a better code. But badly organized code will make this harder, so you tend to think about organization.

I'm not sure that's true. I've heard him talk in several interviews about using AI tools, including in his editor. Definitely not a minimalist setup.

See this interview: https://m.youtube.com/watch?v=v4qE1nzUidg&pp=0gcJCRsBo7VqN5t...

I do this when working on personal projects. I don't go this far though. I still like having syntax highlighting, and I have an LSP on to try in editor feedback on syntax errors, but I don't use auto completete or in editor documentation.

I agree and don’t use any of that stuff—-except syntax highlighting. Why wouldn’t you? Color is a whole extra dimension it adds to the code that lets the eye notice errors more quickly and jump around faster.

I haven’t made the jump yet but I believe you. My autocomplete has been broken on Emacs for a year, and I rarely miss it. I never use code actions, nor goto definition. I do enjoy real time errors but they often pop up with such a lag I’ve ran the compiler and it has shown me the error itself. So I dream of just turning off LSP — it’s not like it makes me such a better programmer than 20 years ago.

Re: syntax highlighting, I don’t know how people can work with their harlequin-on-LSD themes that are a constant distraction with no semantic benefit. I have gravitated around mostly mono or duochromatic themes, while 99% are a vomit of colours. I still don’t get why variables or function names need a distinct colour.

What autocomplete and highlighting has to do with code quality? I would write the same output with and without "assists" anyway.

Wasting your time hunting down a missing string delimiter forces you to read the whole file line by line maybe, so they write better software having read it.

what do you think about ctags? i think when trying to understand a codebase for the first time a tool to quickly look up definitions, etc. helps immensively

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.

To save anyone else the search:

mini.nvim site: https://nvim-mini.org/mini.nvim/

repo: https://github.com/nvim-mini/mini.nvim

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

`hx --tutor` is a life saver though. Did that to quickly catch up on hx keybindings and Claude chips in when I need more efficient things to do certain text editing operations.

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 feel the same way. I've put a lot of time into getting fast and efficient with Vim, so the benefits of another editor would have to be substantial to justify switching. As nice as Helix looks, I'm not sure it offers enough to make that leap.

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

Heh the thing I like about kickstart is everything is in one file, though it is a bit unwieldy, so I surrounded most bits around fold markers to make it a bit more manageable.

interesting! yeah I think the one file concept is really neat. Here are some more details about my config with the modular fork if you are curious https://jarv.org/posts/neovim-config/

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'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)?

I don't know about Helix but Neovim (and vim) has something called sessions and it does everything but unsaved files. By default it's manual but it wouldn't be too difficult to automate. A very simple way could just create/update the session on BufWritePost and ExitPre. Then create an alias to open Neovim with that session: 'nvim -S .session.vim'.

You'll get an error if the session doesn't exist but it's easy to dismiss. There are probably plugins that do this in a more seamless way though if you prefer.

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.

I tried helix a few months ago. Before that, I gave it a try several times. The editor is fine, but I always go back to vim and vscode for these reasons:

- In vim, I can use vim-fugitive [1] to easily run git add and git commit. Not sure if helix has that level of integration with Git (I like the gutter, though). I know that we can use tools like lazygit within Helix, but I think :Gw and :Git commit are more ergonomic.

- I prefer vscode to code in Rust because of rust-analyzer [2]. That plugin gives me type type annotations along each variable. Helix can also provide some hints, but not that many as rust-analyzer.

[1] https://github.com/tpope/vim-fugitive

[2] https://rust-analyzer.github.io/book/vs_code.html

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 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 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 easy setup is exactly the reason Helix has taken off compared to Kakoune. It probably has the most simple onboarding experience I've had with any text editor. Things just make sense, and tools that should be built in are.

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.

I genuinely don't like the concept of the keyboard interaction in helix and kakoune, selecting things to modify them. I don't know what it is, but it somehow just feels much less satisfactory to me personally compared to the vim way.

The problem with that editing model for me is that it makes text objects much more cumbersome.

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.

The biggest benefit is multiple cursors. The helix and kakoune multiple cursor implementation are probably the best in any editor. It just goes hand in hand with selection first.

This bugged me for reasons I can’t quite explain. I think it’s that I can write and edit the command before making the modification and the ease of going back and reusing a historic search and replace relatively easily.

I spent about a month trying to get used to Kakoune. It never clicked with me and I went back to vim.

My biggest beef with Kakoune’s editing philosophy is that it seems to emphasize “editing in the large” as its preferred mode of interaction. This is totally backwards to me. Editing in the large (making multiple identical edits throughout a buffer) is a rarity. Most edits in day to day use are single edits. So the fact that Kakoune likes to leave a bunch of extra cursors in your wake (like a trail of breadcrumbs) as you jump around a file to make single edits is extremely infuriating to me, like it’s trying too hard to be helpful.

The irony of Kakoune using a clippy-style contextual help window is not lost on me!

This is unfortunately exactly why I never used (neo)vim or kakoune (or tbh, sublime text whose lsp integration I have never successfully gotten working). Going from school (Java + NetBeans/C# + Visual Studio) to work (C#/JS + Visual Studio -> C#/TS Visual Studio Code) I had expectations for certain language features being available by default. Helix is the first editor of its ilk to get configuration out of my way so I can effectively write code the way I'm used to.

Aside from the other replies, marketing matters. This is the first I've heard of this thing which apparently dates to 2011.

Kakoune's problem is the bad UI (eg LSPs hover), and that scripting it is simply too complicated.

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 moot.

I've been using vim for 25 years, my muscle memory isn't going to tolerate switching to a whole new text-editing "language" at this point. But I could perhaps learn to live with a new dialect.

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

Appreciate the clarification, I guess I didn't get far enough into `:tutor` to see that.

`ed` is really much more in the spirit of unix. `vi` culture popped up since then, and the idea of driving other tools from an editor is more of an emacs/lisp lineage.

`ed` is in the spirit of teletypes. It's the editor of choice when all you have is a dumb text-based prompt with no control of full-screen display. The whole point of `vi` originally was to be a `vi`sual mode for `ex`, which is a more full-featured variety of `ed`.

>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.

Not sure what "trivial" is trying to convey here, but in any case personally I would put quickfix list as a rather advanced feature. Like in the excellent book Practical Vim[1] its covered in chapter 17 on 21 chapters.

[1] https://learning.oreilly.com/library/view/practical-vim-2nd/...

"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.

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.

yeah, I started using Meld for diffing

Waiting on proper git, diff, and debugger support.

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.

My emacs configuration is around 500+ larger, but that's mostly because emacs is a whole ecosystem. My `.vimrc` is 244 lines and I think the lsp settings is around 100 of that. The rest is mostly mapping and a few plugins (vinegar, surround, fzf,...).

So... have you tried Helix? Covers everything you're asking for, and doesn't require any config fiddling for it.

Helix has no file tree.

My configuration[0] doesn't quite meet all of your requirements, but you might be able to get some ideas from it. If you delete my hacky and very opinionated color theme configuration, it's 418 lines.

- I use Neovim in the terminal, so that's where I configure the font (Hack Nerd Font Mono) [1], which I install via homebrew on macOS[2].

- LSP: Can't recommend mason.nvim and mason-lspconfig enough. Install LSP servers with mason.nvim, and then mason-lspconfig handles automatically configuring and enabling whatever you've installed.

- I'm using mini.icons[3]

- For the file browser, I highly recommend Oil.nvim[4], which I discovered from this video by TJ DeVries[5].

- I was using fzf-lua, but switched back to Telescope because it was a better fit for me personally (I missed C-k to automatically append a file glob to live_grep. I missed being able to toggle the previewer. I missed being able to hit Esc and move around the picker input box with Vim motions)

Might be misunderstanding "splits I can manage with the keyboard", but (Neo)vim is pretty configurable here! I actually just use the default keybindings of e.g.

- `C-w` then HJKL to move

- `C-w C-v` to open a side-by-side (vertical) split

- `C-w C-q` to close the current split

- `C-w C-o` to close other splits (make current split the only one)

- `[NUMBER] C-w C-w` to jump to the [NUMBER]th split.

- `C-w o` to jump back to the last split you were at

[0] https://github.com/wilkystyle/nvim

[1] https://www.nerdfonts.com/

[2] https://gist.github.com/davidteren/898f2dcccd42d9f8680ec69a3...

[3] https://github.com/wilkystyle/nvim/blob/db16245731dea45f0c58...

[4] https://github.com/stevearc/oil.nvim

[5] https://www.youtube.com/watch?v=-r1mMg-yVZE

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)?

It has both? Granted, Ctrl+D requires manual construction from a sequence of commands, but click to place extra carets works as is

> requires manual construction from a sequence of commands

Right, I saw some people share some snippets here before. But none of them act like Sublime does. I can't double-click a token and Ctrl + D to select next instances of it in my file.

A-s = ["save_selection", "select_mode","search_selection","extend_search_next"]

you select a token, then pess alt+s to select the next instance and so on

That limits to only 2 selections. If I keep pressing Alt + S, it does not select multiple instances of the first selection.

Also, I can't immediately start typing like in Sublime to replace the content. For example:

"test/filenameA.c"

"test/filenameB.c"

"test/filenameC.c"

"test/filenameD.c"

If I select test/ with the cursor, then A-s, it won't select 3 and 4. If I do this, however:

C-d = ["search_selection", "extend_search_next"]

It does select test/, in all 4 lines, but I can't immediately type "blah" to change test to blah.

It's very funny to me that some comments before someone wrote that helix has the best multiple cursor implementation.

I was curious about what could it be.

Then you mention it doesn't have two essential behaviours that I am used to, and I wonder if these people just know vim and cli editors and that's why they have such opinion. Because I am also a SublimeTexter.

Cmd + click places multiple carets on macOS. Apparently – I never touch the mouse when I’m editing in Helix. I don’t know which modifier it is on other platforms.

I’m not sure if replicating Sublime’s Ctrl + D is possible or not, but there are other ways to achieve every use case for it I can immediately think of. e.g. I think I’d typically be doing `<space>h` to select every instance of the symbol under the cursor, or using `s`elect to reduce a selection to a match, possibly yanked and pasted.

There might be a better way but this bind works well for me in normal and select modes.

  C-n = ["search_selection", "extend_search_next"]

Does not work on Linux. Also, double-clicking to expand selection like in Sublime does not work.

https://github.com/helix-editor/helix/discussions/10208

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.

"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 use Helix and Zellij and it has been amazing, requiring very minimal configuration and maintenance.

from my `/etc/tmux.d/keyboard-shortcuts-comfort.conf`:

    bind-key j command-prompt -p "vim:" "new-window -c '#{pane_current_path}' 'stty -ixon -ixoff && vim %1'; select-pane -T '%1'"

This binds `j` to prompt for files to open (* or just hitting enter works) and launches vim in a new window in tmux (turning off flow control and setting filename as title). Probably one of my most-used shortcuts.

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

Indeed, Vim has had ways to do this for years, before nvim. I suppose their point is that it comes out of the box? It is worded in a way that makes it seem like they think like there are no options.

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.

I think showing live preview for replacements is also a built-in Neovim feature now, but I can't remember if it's enabled by default or not.

I suppose it is, my Neovim has always done this.

That is not the same as helix multiple selections. I suggest trying our helix to really understand.

I really liked helix, but the problem is that pretty much everything I use is setup using Vim bindings (shell, browser, ideavim,...) so switching to helix concept of editing was different enough to require effort, but close enough that it screwed up all my other muscle memory.

Fair enough, I definitely made some assumptions there, but it sure sounds the same based on the description. I guess `%` selects more than just the token?

But ya, I'm way too invested in Vim to bother with Helix. I have years of scripts and plugins I've written. I can't even be bothered to switch to nvim (I tried once and was not fun).

“%” is a range operator standing for the entire buffer; so :%s just means to start a substitution on the whole buffer. Neovim will highlight what was previously searched for, in this case matched by the *, but that won’t actually affect the search command.

The way :s works in Neovim looks like multiple cursors to me, but I’m not familiar enough with Helix to know what the difference is.

Ya, yes sorry, well aware of what `%` is, I was leaving out a lot of context there. Of course, as it turns out I was thinking in terms of my own mappings and not even then, I'm not sure why I thought `` came into play because my mapping is `gysiw<space>` (`w` can be replaced with other text objects) which populates the commandline with `%s/\<'.expand('<cword>').'\>//g` (and moves the cursor left twice). I just press `` a lot, sometimes even before replacing because I have it remapped to not autojump to the next match and rather `set hlsearch`. So ya, I'm all kinds of wrong bitten by my own config, lol.

Also :s without a range is not going to work like multiple cursor as it only acts on the current line, unless neovim has changed this for some reason. But again, I was assuming //g was a given.

If %s is Vim's answer to multiple cursors, then it's hopeless. I'm using both VSCodim and Vim, the former when doing dev, the latter for quick editing remotely through ssh. Tried Helix but it kind of annoyed me after years of using Vim.

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.

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)

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

I think a lot of people on this site have genuine reading comprehension problems. I mean that as an observation, not an attack.

> "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.

When someone is competent, as must be after using a tool for 20 years (not days). Expecting that someone to complain about a difficulty for something trivial is surprising. There are other ways to highlight that it is easier or simpler in Helix to have working LSP, for example, saying it is "as easy as in vscode". But it is definitely bewildering why would the OP choose to start by bragging of the vast experience, and then focus on a complaint that most people expect from someone who has very little experience.

> Expecting that someone to complain about a difficulty for something trivial is surprising.

Is it? It isn't to me. It's expected, to me. As I've gotten older I've gotten much, much less tolerant of convoluted and unnecessarily complex hoops (which I collectively call "bullshit") that must be jumped through in order to get something working. Especially when there is an alternative nearby which puts me through zero hoops.

When I was young and Linux was brand new I had all the time in the world for compiling, patching, debugging, fixing, compiling, testing, deploying, logging, parsing, notifying, writing tooling and customizing. As I enter my 6th decade I have zero time for most of those things. The mere thought of that kind of thing today for almost all software is anathema. And anything that makes me do anything that should have been sorted out by the software author but wasn't immediately goes to the bottom of the list of consideration for any purpose in the future.

> LSPs its too hard". What?

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

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?

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

> 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.

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.

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

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

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.

Out of curiosity, what in a broad sense is configured in those 10 lines? (For context: I'm a Helix user trying out terminal-based vim at the moment and I'd like to know what the most important tweaks are.)

some basic ones like:

syntax on

set number

set expandtab

set tabstop=4

set modelines=0

set nowrap

and then a few related to ctags.

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

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.

Helix very much is not a Vim rewrite in Rust. It's closer to a Kakoune clone than a Vim one.

Zero config distros still require maintenance, and the chosen tools change over time. Helix is just Helix

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.

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

Vim is life, no need to change

It’s true. Once you master Vim, your journey to find the perfect editor will have come to an end. For the rest of your career, you can rest assured you will be using some form of vim.

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.

I use both helix and vim every day. After a while your brain just adjusts. It's like playing on playstation and nintendo for a long time. Eventually as soon as your hands touch the controller it switches to the appropriate mode.

What are your differing use cases for each editor?

My work setup is simply too complex and uses too many plugins to work in Helix as of now.

For all personal work and just quick text editing I use Helix. If I could use Helix for everything I would

Where does evil-mode land?

From what I have heard, evil-mode does not give you an ability to touchtype, I mean totally blind typing without any pesky Escape Meta Alt Ctrl Shift chords.

I just heard of Helix and decided to take it for a spin. I'm not sure why I'd use it instead of Vim.

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...

Having separate commands for creating/modifying selections and for editing their contents is more orthogonal. In kakoune, you can select a word, multiple words, multiple search results, a brace-delimited block, or an arbitrary sequence of characters (it's pretty common that I want to include a bit of whitespace, or instance), and the same 'c' command works on all of them. The same 'd', 'i', and 'a' commands also work on all of them. In straight-line editing it's no more keystrokes than vim, and hardly more than any other editor, but for complex operations it lets you tailor and preview them as you go. The thing that confuses me is why it would even be a debate that this is better.

Because immediate visual feedback is more natural than having to imagine an operation in your head, it's the same logic for multiple cursors - where it's even harder to understand what "change this word" will actually change.

> why THAT of all things?

Because that's a fundamental improvement

There were a few blogs with more detailed explanations, not sure about Helix, but kakoune had it covered https://kakoune.org/why-kakoune/why-kakoune.html

> Kakoune tries hard to fix one of the big problems with the vi model: its lack of interactivity. Because of the verb followed by object grammar, vi changes are made in the dark, we don’t see their effect until the whole editing sentence is finished

the lack of a `gq` equivalent to reflow a paragraph, which julia mentioned, was the nail in the coffin for me when I tried it.

It's a nice project though, I just use that feature constantly

in kakoune, this is `<a-i>p<a-j>|reflow<ret>`. which is obviously not as simple as `gq`, but you can rebind this, add things like auto-reflow as you type, etc., rather trivially, and rebind them (and a lot of these types of tools come preloaded as bindable commands). it's some work to set up this type of thing (and it makes perfect sense to use e.g. vim to not need to do that), but i like the composable design, where i can write some configuration to hook a shell command to a bind, rather than fork and PR changes (e.g. a c++ reflow function), and the config files can be written and PRd into the default distribution as well, so the user experience would be equivalent.

> i can write some configuration to hook a shell command to a bind

is `reflow` a binary that comes with kakoune or something?

'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.

I’m curious about the particular program though! On my Mac it doesn’t exist and I didn’t find it in a quick search

Honestly, it might have just been a placeholder name for an arbitrary formatter. I vaguely remember old-school unix had a command for that, but none of them seem to be named exactly "reflow".

apologies, i probably should've written `fmt` there (which does the same thing). `reflow` is a `fmt` clone i wrote, without the knowledge `fmt` existed --- that was a bit embarrassing for a friend to eventually point out, that my idea was already in coreutils :D i use `fmt` now because i figure it's far better tested (i think it's posix), but i still think of the action as a "reflow", and that's also the term helix uses.

(for kakoune, not helix) i've used kakoune daily for almost 2 years now, and i still mix up e.g. `(?<!` vs `(?!<` for lookbehind regexes. i appreciate the ability to select a region and watch whether my regex has selected what i expect.

but, this is probably less important than the simplicity of the selection first model, as it ties into multisel, etc. a selection is a cursor and an anchor. other keys manipulate the selection(s) in very particular ways, which are predictable. external tools interface easily with the selection format, as it represents cursors and anchors.

each benefit taken alone is quite small, but together they offer kakoune a very lean, predictable design when combined with its use of external programs for tasks like sorts or paragraph reflows.

helix is similar to kakoune w.r.t. the editing model. kakoune has `w` to select the next word (and move the anchor to the start of the next word), and `W` to select the next word (and keep the anchor where it is, so you now have two words selected). helix has `v` to enter visual mode, which is essentially equivalent to caps lock with kakoune --- `vw` in helix is equivalent to `W` in kakoune (i believe).

i think selection first is better, but i think it's fair to prefer vim's style, obviously. but there's certainly ample reasoning, though helix might not explain it thoroughly, because (at least, at one point) they may have expected users to have viewed kakoune previously, and understand its philosophy, as helix is essentially a batteries-included kakoune (and kakoune explains the reasoning quite thoroughly).

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.

But how much do you have to find, vet (how much do you trust Telescope to not steal your credit cards one day), and install for all the features of helix?

And you can vet that Helix will not be stealing your personal information now and in the future? What an asinine comment. There is no security, the computer is spying on you, you can't really vet anything.

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

Vim and Emacs are too different to help you in one comment. At least you need to choose one of them by your own.

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

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?

No. Noun-verb is central to the design. Everything is built around it.

The best writing about this is "Why Kakoune" (Kakoune inspired Helix): https://kakoune.org/why-kakoune/why-kakoune.html

Not really, there is a config and some patches (helix-Vim IIRC) that gets you close, but it is still different. It also feels like you're throwing out helix main selling point.

* Too late to edit but of course I meant Vim's verb-noun syntax.

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.

I'm not sure why you think Lisp makes this "emacs" unless you're worried it'll fall flat because most Lisp-interested folks would find emacs more full featured? I'm not sure if a Scheme is particularly different than neovim's Lua. I'll be honest though I'm not sure how deeply Steel is integrated into Helix.

It's not integrated at all right now. It's still sitting in a feature branch unfortunately.

Ah I thought the big branch finally got merged.

Not yet. PR is still open and waiting for someone from the team to review. I suspect this won't be an easy thing.

Don't worry, Fennel compiles to Lua so you can keep configuring Neovim with a Lisp dialect too!

It's very hard to argue the plugin system has made Helix anything in particular, considering it is not merged yet. Approximately nobody's experience of Helix up to this point has been influenced by this choice.

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.

<Controversial opinion> Computer scientist and mathematicians love lisp/scheme, everyone else hates it. The problem is that the syntax, concepts etc are so different that you really have to learn the language to make even small changes. Just reading prefix notation takes quite a bit of adjustment. When I was using emacs doom every time I changed my config felt like stabbing in the dark (hence I moved away). In contrast I could make lua changes (without any prior lua knowledge) without any problems.

I don't want to learn a new language just to configure my editor.

So by choosing scheme they essentially say this is an editor for computer scientists only. </controversial opinion>

Lisps make great configuration languages because of how dynamic they are. It's like Javascript on steroids. Redefine core symbols. Modify a syntax form and reevaluate all of your code so that it does one thing in one environment and something else in a different one. When building large software in a team this can be a big drag; learning some weird syntax form that a coworker merged in that you didn't review can be a headache and when everyone makes their own design patterns, the codebase becomes a mess.

But when you're just configuring software this heavily dynamic nature becomes a strength. I just need to build the abstractions in my config that I need, nobody else. It's easy to poke around in and spend a few minutes writing and iterating on code to get the config I want.

I agree that the prefix notation and the soup of parentheses give it a higher learning curve than something like Lua which is easily understandable if you have experience in pretty much any modern programming language. But it's not the mathematical/computational purity that makes Lisps appealing, it's their highly dynamic nature.

Reply on news.ycombinator.com