> 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.
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.
> 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?
>> 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 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.
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).
> 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.
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?
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.
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.
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 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 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
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 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.
> 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.
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.
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?
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.
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.
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 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.
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!)
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.
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.
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.
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.
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...)
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 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.
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 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 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.
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.
`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.
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.
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.
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.)
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 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?
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)
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).
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 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.
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!
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.
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.
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.
`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`.
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'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 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 =.
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.
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.
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.
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.
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 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.
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
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 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.
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'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.
> 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.
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.
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.
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).
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.
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.
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.
> 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
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.
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.
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.
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.
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.
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.
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.
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.
<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.
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.
> 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
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.
Getting LSP to work on recent versions of Neovim is now easier than ever. Say you want to enable clangd. It's one plugin + one line of configuration:
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
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.
This. Now that LSPs are natively understood by neovim it's a very painless process. Especially if using mason to fetch the language servers.
> 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?
>> 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 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
> 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.
You’re going to hate that my shortcut for Normal mode is j-k, and I don’t have any other j-* commands.
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.
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
what's left? 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.
If you need something between nvim and vscode what's the issue with using vscode with vim plugin?
> 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.
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 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
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 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.
> 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.
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.
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...)
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.
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.
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
Totally weird. LSP has been a neovim builtin for how long now? Two years?
4 years. 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!)
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.
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'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
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
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 can see no plugins, I can even see no autocomplete but no syntax highlighting is just making things difficult for the sake of it
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?
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.
The true Plan9 aesthetic
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 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.
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 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!
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?
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.
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.
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.
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.)
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 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?
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)
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 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.
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!
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.
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.
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.
Kakoune's problem is the bad UI (eg LSPs hover), and that scripting it is simply too complicated.
`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`.
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'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)?
"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 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 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.
Waiting on proper git, diff, and debugger support.
yeah, I started using Meld for diffing
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.
"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
solves this issue nicely for me.from my `/etc/tmux.d/keyboard-shortcuts-comfort.conf`:
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.I use Helix and Zellij and it has been amazing, requiring very minimal configuration and maintenance.
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 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.
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?
> 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 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.
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'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.
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.
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.
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.
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).
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.
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.
Vim is life, no need to change
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...
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
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.
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
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?
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.
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.
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.
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.
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.
Helix very much is not a Vim rewrite in Rust. It's closer to a Kakoune clone than a Vim one.
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
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.
<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.
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.
Don't worry, Fennel compiles to Lua so you can keep configuring Neovim with a Lisp dialect too!