How I'm using Helix editor | Hacker News Reader

How I'm using Helix editor

rushter.com

216 pointsf311a91 comments

I've recently been on a little side quest to rebuild my editor configurations (20 year Emacs user, 15 year Vim user—in parallel with Emacs because I can't seem to pick a favorite). The goal is to see how quickly I can get to a daily-driving complete setup for enterprise-grade software work largely in Python. My goal for the rebuild is to see how much I can drop as far as reliance on third-party extensions and still have the functionality that I need (or which makes me unreasonably more productive).

My Neovim configuration[0] is currently the best it's been IMO, but I ended up having a few more plugins than I thought I would need.

I am earlier along in my Emacs rebuild, but what is really interesting to me is that there are a lot of improvements in modern versions of Emacs (30+) that dramatically reduce my dependence on third party plug-ins. Eglot has been fantastic for me, as a former long-time lsp-mode user. Completion preview mode is not quite a replacement for corfu, but it's pretty darn good and only going to get better.

So far my list of must have plug-ins for Emacs:

- Magit - Expreg (teeesitter expand region) - Multiple cursors - dape (debugging in coordination with Eglot)

Thinking I will probably end up adding Consult + orderless, too, as that is a search/navigation superpower.

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

edit to add nvim repo link

That is quite a lot of nvim plugins to maintain! I just rewrote my nvim last week with 4 plugins (mini.nvim counts as 1). I feel when I stack up too many plugins the stability and reliability of nvim plummets to an annoying level.

I envy that with emacs you feel you only need 2 plugins. That probably operates with a ton more stability.

https://codeberg.org/dannyfritz/dotfiles/src/commit/b647b440...

Newer nvim is also slowly eating into the plugins needed. There is a built in plugin manager, diff viewer, and lsp now.

Undotree functionality was recently merged in too.

What is nvim built-in diff viewer? Is it just `vimdiff` / `nvim -d`?

https://neovim.io/doc/user/plugins.html#difftool

Yes! I was very happy to see this. It's simplified my configuration a little bit, but there are still some niceties I would consider as necessary in order to be productive, so I am using Mason, mason-lspconfig (automatically configure and use any lsp servers installed by mason), and Blink for fast and ergonomic autocomplete popup.

IMO Neovim OOB experience isn't quite as nice as what Eglot and completion-preview-mode do for the Emacs OOB experience, but I love that every time I check back in on the latest state of either editor, they are sensibly adding really solid functionality to the core that continuously reduces my reliance on third-party plug-ins!

Not a diss but even after spending O(months) do you think it's as good as what you get with Pycharm + IdeaVIM out of the box?

Of course, there are other reasons to build your own configuration but I found purely from "IDE as means to an end" perspective getting into Neovim rabbit hole is a bit of waste of a time

I imagine Pycharm would still be better at refactoring (extract method/variable, in-line variable, etc.) LSPs are good at renaming, but not much else. There's a plug-in, but it breaks very often.

This is a great question! It's also a really hard one to answer.

When newer developers come to me looking for a recommendation of an editor to use, I don't often recommend Neovim, and I pretty much never recommend Emacs. I do recommend learning Vim motions, however, and my go-to is VS Code with the vscode-neovim plugin (uses actual nvim binary under the hood—no crappy emulation slowness/inaccuracies!)

For me personally, I've never met a situation where my Neovim or Emacs configuration couldn't handle a refactor or some other thing an IDE does. And then with all the other things like search/navigation (Consult+Orderless in Emacs is unparalleled) and working with files, git, or the filesystem (dired-mode in emacs, Oil.nvim for Neovim)... I'm just so much faster in one of those two editors than I am in any IDE. The ability to do everything you need in a single tool using the same paradigm and keybindings and concepts to get all of it done is pretty powerful.

I do also have a nervous aversion to using products that are not fully open source. Probably an OCD fear of losing full control over my editing and development experience.

I'm very interested in reports of 10+ year users of Emacs, how do Helix/Vim compare? I understand reports from zero-to-Helix/Vim users that they're good, but I don't believe they truly understand how great Emacs is unless they really use it for a long time.

But because Vim-like keys and modes seem to be so much better integrated in all other editors these days (no good Emacs mode in VSCode for example), seems like it won, and it'll soon be time to accept that.

But every time I tried – I never had enough patience to use it until my fingers have the memory, and didn't see the point enough to keep smashing the editor.

So, very interested in reports of actual hardcore Emacs users about the switch.

I'm not a 10+ year user of emacs, and have switched from vim to emacs. But here is my 2 cents if you're willing to take it.

Vim (and variants) is a language for editing first, and an editor second. Most of vim parts from a text editor perspective is found in some way or others in other editors. It's biggest pro is being centered about the vim language of editing. Once you master that, editing is very fast and you can extend the language easily by using external tools. And there's already a good number of integrations through builtin mechanisms and various plugins.

Emacs is a collections of tools for working with textual interfaces. Where Emacs easily wins is how easy it it is to integrate with anything that plays with text, (which is basically everything). The good part is that every plugin (even builtin one) is a software, a library, and a playground at the same time.

For me personally, there's probably too much to put in a comment, but the essence of it is:

- Vim modes are prolific, but they always fall short in some annoying way (Jupyterlab-vim plug-in is so bad it's almost not even worth considering Vim emulation). I inevitably find myself missing the full power of true Neovim, especially with the live find/replace in the buffer, `:cdo`, and things like `:g//norm` (which could be an entire tutorial in itself!)

- Emacs: I have never met another editor (or even piece of software) that is not only so customizable but so designed to be customized. It's really hard to capture it in words, but it's such a comprehensive ecosystem of tools that all are designed to work together incredibly well and designed in such a way that when you make your customizations you can do it in a way that everything still plays really nicely together. For example, I can use Tramp to make my local, fully-customized Emacs edit on a remote filesystem as though my local setup is there, any arbitrary number of SSH hops away, even sudo'd to root on the target machine. I can further leverage the built-in /docker: protocol to edit with my local editor, on that remote machine, as root. Eglot plays nicely so my local editor uses remote LSP servers. dired-mode plays nicely so that I can browse and modify the filesystem on the remote target with my local editor. Because everything is nicely integrated together, pressing M-! to run a shell command while editing a remote buffer will run the shell command on the remote target in the same directory as that remote buffer. Similarly, M-x shell opens a terminal window on the remote target, in the same directory as the remote file I'm editing, as whatever user I have sudo'd to (if applicable). And it does everything with pure SSH, no remote daemon needed. And then there is the customization. Vim/Neovim score very well on the customization front, but I guess the way I would put it is that the difference in philosophy is that Vim/Neovim (and most other customizable software) are applications for which the developers give you a ton of APIs to affect the behavior of an otherwise closed system. With Emacs, by contrast, nearly all of the system is open. There are compiled C functions at the core, but anything in lisp is there for inspecting and modifying in real time while the system is running. And for all the things that are compiled that you cannot affect, there are further paradigms such as the advice system, which allows you to modify built-in behavior by wrapping existing functionality with things like pre- or post- actions (among other things too numerous to get into in a comment). emacs is built with the philosophy that there should never be an area of the software that you don't fully own, control, and have the ability to inspect and understand.

I guess this turned into a classic Emacs-nerd rant about why Emacs is great, but to answer your question the long way:

There's no Vim like (Neo)vim, and if you are an advanced enough (Neo)vim user, everything else falls short in ways that suck.

And there is simply no software I have ever come across like Emacs. It takes a lot of work to make it your own, and I totally get that is not for everyone. But if it is for you, everything else is too limiting.

(maybe to answer your actual question, I've never successfully made the switch. I always come back.)

Thank you for the detailed report!

Anothing thing from my recent (couple years) discoveries is that emacs is actually pretty good out of the box, so on my servers/containers I just started doing `sudo apt-get install --no-recommends emacs-nox` and use that. The only annoying default is the need to disable the "backup files".

I switched to Helix 2 years ago after 28 years of emacs and didn't look back. My emacs config was huge, and I didn't enjoy all the tweaking I was doing to get LSPs to work the way I wanted. I had tried evil mode (and vile before that) without really getting comfortable. I think the Kakoune-style order clicked much better for me than vi descendants. Also, the multiple cursors in Helix work so much better than the equivalent emacs plug-ins. The only thing I really miss is tramp. I liked magit a lot, but jujutsu obsoleted that for me.

> Expreg (teeesitter expand region)

reminds me of combobulate (which i haven't tried but think looks cool) but sounds much more light/limited

I think that is an accurate assessment! It's actually the reason I prefer it. I only wanted the ability to expand to treesitter text objects and then contract that selection if desired. I almost wrote it myself but then found that plug-in.

Slightly off topic here but do you (or anyone) happen to know how to get old Eglot behaviour back of showing entire types and parameter information instead of only the first line? It has been bugging me whole week and I cannot seem to find any fix for this.

Are you referring to the eldoc help text in the echo area at the bottom? Hard to know without more specifics, but maybe one thing to check might be the value of eldoc-echo-area-use-multiline-p. I have mine explicitly set to `nil` because I find the default eldoc behavior of constantly resizing the echo area to fit more information to be very distracting. I instead have a keybinding to call `eldoc` (an alias for `eldoc-print-current-symbol-info`) on demand, which opens a side split that shows the full symbol information.

Yes I am talking about the help text in echo area. In newer versions apparently they only show a single line by truncating the eldoc-doc-buffer content(not super sure on this but they do truncate to 1 line). eldoc-echo-area-use-multiline-p does not work for that sadly.

Apparently this was changed only recently. I am surprised not many people know/talk about this change. Still looking for a fix.

Edit: I do agree it is annoying but for unknown codebases it helped me a lot.

I also like to view entire doc even jumping. I created some Eglot additions here https://github.com/cxa/eaglet which have an option to enable this behavior if it would help.

BTW it's crazy how good Claude Code is at emacs configuration, and in fact elisp writing in general.

I also switched from lsp-mode to eglot and it's better. Less fragile.

> I also switched from lsp-mode to eglot and it's better. Less fragile.

I agree with this, and it's a big reason why I made the switch myself. I also find myself favoring lightweight (and especially builtin) capabilities, because really large, comprehensive plug-ins tend to have their own paradigms or ways of doing things that break from the super well-designed Emacs system of everything just working together magically.

I'm an Emacs -> VS Code -> Helix convert, have enjoyed using it thus far. I've tried to internalize all the existing keybindings and use thus far rather than configuring it much ( I've wanted to have the least amount of config necessary to be effective with it )

One thing I've struggled with is simply remembering everything it can do. I made a Desktop Mat[0] to help remind me ( literally just finished it so will see how helpful it is when the printed version arrives ).

[0] https://git.sr.ht/~netshade/helix-deskmat

For how long have you been using Emacs before?

I was an Emacs user for about 3-4 years. I never felt very proficient in it, I always felt like I was cargo culting in config changes that I never felt comfortable with. I liked the power, but never graduated to the point where it felt like it was working with me. AFA why I didn't switch to Vim, there was enough "Vim is great with a great config" which felt so similar to the situation I was already in with Emacs that I just wasn't convinced. Not the greatest rationale, but that's what it was.

Were you vanilla or some prebuilt configuration like Doom? I started by copying someone's (vanilla) config and get everything that felt right for me. Then I went on to other people's config (also vanilla) to get what they have that was different and the rationale behind it.

I'm still editing my config every now and then, but mostly smoothing out interactions with the software. Latest was configuring magit to have a speedier interaction by removing some stuff I don't care about.

Started vanilla and importing things like projectile, magit, all of that. I didn't like the awkward edges of how they joined tho, and eventually tried switching to Spacemacs with "less" of my own config. None of it was awful, but none of it felt great.

When VSCode came about and had great integration for a language I was primarily using at the time ( Typescript ) I switched to that and was happy for the comparatively low config required. My Helix switch came about just because of how VSCode absolutely chewed through battery usage when I was out and about.

I've been using emacs for the last 10 years or so (used Sublime Text before that). I use vim as well from time to time for quick file edits here and there or on remote servers and thought it's fine for that purpose, but I didn't really see the need to use vim exclusively. I'm pretty well settled on emacs now and have my own carefully written modules and functions to get the right setup for me.

I tried helix last month and was immediately hit by how simple it is to get started. It still doesn't come naturally to me, but I managed to quickly get used to the basics: jumping around code, search, yanking/pasting stuff, and switching buffers and windows. I have no idea about its history, but Helix is a very well designed piece of software. Global search is particularly nice, lsp integration just works, it's also exceptionally fast. It feels very nice and comfortable when a software has sane, coherent, and actually-helpful defaults.

I'm definitley going to keep using it and getting myself more accustomed to this way of editing, I will keep emacs as my default, but helix is just so fast it might become my go-to over time for editing code.

At this rate, why not use vim? Half of the configuration is re-creating vim inside Helix. Not to mention, Helix has many dependencies (you just don't see them the way you do in neovim). I think I could make a case that my vim setup is more supply chain safe than Helix.

My current vim8 setup is very simple and has served me well for 8+ years. I'm currently using vim8 because it's what is available within my LTS distribution.

I only use one automatically loaded plugin (`vim-tmux-navigator` to simplify moving between vim splits and tmux splits, it's a passive plugin). I have reviewed the code for the plugin and I don't update it.

I only use two "optional" plugins (you can enable them using vim's built in package manager with :packadd!). I use `ale` (lsp, diagnostics and automatic formatting on save) and `vim-fugitive` (git workflow inside vim).

Why use ale? Because it works with vim8 and doesn't require any other dependencies like nodejs or python. I have reviewed the code and I'm happy with it. Install it and use it, don't update it without a reason.

Why vim-fugitive? It's a productivity booster. You install it once and forget about it. Tim Pope is the man.

I don't automatically load plugins (besides tmux-navigator) for a few reasons. Most of the time when I'm using vim it's for quick editing where I don't need the heavy tooling (like git integration or an lsp). If I am working on a project with a long term session I will enable git and lsp.

There's no need to automatically run code unless you need it.

Helix's editing model is better.

I've tried for 2-3 months and I had no problems with the editing model. My main issues were with the general UX (text moving around with diagnostics, balloon windows covering your input, etc). That's in addition to my other issues (you need to install it, it's not available everywhere, etc).

The surface area for supply chain attack with Helix is vanishingly small compared to nvim + n extensions. You’re dealing with a single vendor, versus one per extension. Helix also runs a very slow, deliberate release process, so while it’s certainly possible that a supply chain vulnerability could be shipped, the process in place appears to work well to mitigate it.

> I'm currently using vim8 because it's what is available within my LTS distribution.

I have come to love modern Neovim so much that I wrote a simple Python package[0][1] to solve this issue, at least for folks who already have to work within the Python ecosystem and use tools like `uv` or `pipx`.

You can install Neovim 0.11.4 (latest version as of building that package) with `uv tool install binwheels-neovim` or `pipx install binwheels-neovim`, and quickly be up and running with a modern Neovim on Windows, macOS, or Linux.

The package just wraps the official Neovim releases and relies on uv or pipx to select the right binaries for your operating system and architecture. The exception is Linux, where I actually build the binaries from source in a manylinux container[2] because I wanted older GLIBC support than the official Neovim releases are compiled for. Was tired of the official releases not supporting the older Linux systems I often need to work on.

[0] https://pypi.org/project/binwheels-neovim/

[1] https://github.com/wilkystyle/binwheels-neovim

[2] https://github.com/wilkystyle/binwheels-neovim/actions/runs/...

I’m checking out helix for the first time, and two serious drawbacks come to mind:

- if a main point is modal editing, vim lets you use your muscle memory everywhere, since vim mode is pretty common (plus extensions like vimium, and almost certainly having vim on any machine you ssh to).

- helix seems to be both opinionated about simplicity (no terminal integration) and not very extensible with plugins (no linting unless it comes from the lsp)? That seems to be a limited combination, forcing you to have your whole setup built upside the editor (tmux etc).

I’m not saying this to disparage the project, just wondering: what are the big upsides that balance those cons?

> - if a main point is modal editing, vim lets you use your muscle memory everywhere, since vim mode is pretty common (plus extensions like vimium, and almost certainly having vim on any machine you ssh to).

There's not a lot of devs who want to directly use the basic vim experience (without any plugins/config). Even with similar keybinds, most devs aren't going to want to switch between editors. Instead, most devs are going to want to use an editor with a personalised setup and set of capabilities. The exception are those few devs who are actually sshing between many machines with a raw-dogged editor experience because it's a hard requirement, in which case they can continue to use nano, vim, vi, emacs, ed, etc...

> - helix seems to be both opinionated about simplicity (no terminal integration) and not very extensible with plugins (no linting unless it comes from the lsp)? That seems to be a limited combination, forcing you to have your whole setup built upside the editor (tmux etc).

Helix was actually built with the intention of having a whole setup built inside the editor, but that's not what the community wanted. So helix has been transitioning into adding a plugin system so the community can turn it into an all-in-one editor. The plugin system is not enabled in the main releases yet, but it's been in it's own branch for a while with a community of plugins already developed and with devs using them now. But all things considered it is the right move to hold back the release and get the shape of the plugin system as good as possible, because if it were released then needed to be changed, you'd be negatively affecting all the plugins that were released before the change.

---

The biggest upside is fixing the poor UX decision that's been baked into vi and carried into vim and neovim. That being, the order of operations which make it harder to see your changes before you commit them, making unintended side-effects easier to occur.

What's the con of the LSP? I'm not familiar with the concept, it sounds like LSP is running in a separate process (which honestly sounds good to sandbox plugins, though I could see it being problematic, I wouldn't be surprised if in practice it functions better to most "integrated" language plugins in other editors.)

As far as tmux I'm a heavy emacs user but honestly I use it mostly as a text editor, I use a separate terminal emulator almost always. So lacking tmux... not something I would notice.

Relearning my Emacs muscle memory is the most daunting thing, but I could probably be convinced for a fast editor written in rust with good defaults.

A language server consumes a lot of RAM even when it’s not doing anything.

I have a very extensive neovim setup, and was reluctant to try out Helix, but this morning I installed it, and I am totally amazed what this editor delivers out of the box! Woooow! This is unbelievable. Totally fast, smooth, and has all the settings I had configured over days in lua and with the telescope plugin. How did the makers of Helix know what us hackers need, want, as if they reviewed my config file :D

For people who use helix and want a TUI, why choose this over neovim? I like the defaults in helix until I don't, and then have to change stuff.

For people who use helix and want the full IDE experience, why not Zed, or maye even VSC/JetBraind IDE (come to think of it, how's fleet doing?).

If i need something simple I fall back to nvim, and if I'm missing features I sometimes boot up WebStorm (or if a colleague wants to navigate through something)

Speaking to the second point, it's clear that some folks will avoid quitting the terminal at all costs. I could very well be one of them. :-D

Personally, I don't like the idea of maintaining 500+ lines of config with tens of plugins. Setting up neovim from scratch is pretty tedious. Using something like lazyvim sets up 50 plugins, which are updated by simply taking the most recent commits from respective git repositories.

It’s only a matter of time before someone deploys something malicious to one of those 50 plugins.

Language support in JetBrains IDEs is top-notch, but they consume a lot of resources and do not work well for remote development in my experience. I still open them from time to time to do complex refactoring. Also, I just hate the idea of opening Goland, RustRover, and PyCharm at the same time. I have a monorepo at work with multiple languages.

How do people get such large config files? I have been using vim for 20 years and my config has grown to 33 lines, 8 of which are blank or comments. I probably use a dozen plugins, which typically add between 0 and 2 lines of config each (syntastic being an outlier, making up fully half of my non-blank lines)

Most people have to work with multiple languages, each of them takes around 20 lines, and blanks + comments add up as well.

As someone who spent some time over the last few years working through trying to daily drive neovim, helix, emacs, and nano, the out of the box experience with helix is far and away the best experience of them. The defaults are very well chosen. Additionally the contextual help and hints are very good for helping you use and remember commands you don't use often. I also personally found that helix's order of operations for commands to make a lot more sense to my brain compared to vim's.

Part of it for me is that I really don't like the massive plugin / config wall that is the modern neovim/spacemacs experience. I truly appreciate the extensibility and the fact that those plugins allow for things helix just can't do right now (e.g. emacs is effectively the IDE for any lisp language and you can't load up a repl in helix). But the problem with that becomes not only do I need to learn the application itself, but now I need to learn a whole bunch of plugins, and often learn about the differences between them because everyone has their own preferences in combinations, so looking up how to do something covered by a plugin often leads you to multiple incompatible answers. And even if you bite the bullet on trying to build your own config from scratch (which I did with emacs) you're still often just taking on faith other people's recommendations on stuff, or spending a lot of time learning about a plugin to make a decision and that time is time you're not spending on whatever you want to be doing.

Helix benefits from being new and not carrying generations of legacy decisions behind it. As a result, helix can make decisions and defaults that fit "modern" expectations. It's not perfect by any stretch of the imagination, but it's also probably what I would recommend for someone "new to the TUI" as a place to start when you just need something with a good chunk of modern conveniences and don't want to spend the next few weeks getting the editor configured.

I really like the great defaults helix comes with.

I used neovim for 20 years and still like it a lot. But after some plugins broke I wanted to give helix a try. I am missing a plugin system in helix.

However, for me, helix comes with the nearly perfect amount of functionality, while being extremely responsive. It also made me appreciate stuff like multicursor, which I haven’t tried before.

I tried multiple out of the box nvim solutions, but never liked one of those.

I looked into zed, but don’t see much of a reason to use it. Maybe I should give it a try.

> I used neovim for 20 years and still like it a lot.

Whoa neovim's been around that long already?

No it’s not. I was using vim / nvim interchangeable. I moved from emacs to vim in 2003 or 2004. I am really not sure when I changed vim to nvim as I always have an alias vim=nvim.

I do a ton of work on low-power devices over SSH. Helix launches almost instantly; neovim with a similar level of functionality (via plugins) has considerably more startup lag and considerably more maintenance cost (config / plugin updates). I also know enough rust to try to help fix bugs but don't know any C family languages; I have a strong preference to use open-source projects written in languages I know.

EDIT: for context I'm a hobbyist who use n/vim for 12 years or so before switching to helix for the last couple of years. There are several things about nvim behavior that I still miss quite a bit and still feel more natural, but the instant startup of helix vs a second or two for nvim configured to a similar level of functional makes it totally worthwhile for me.

I suspect editor choices are not super rational. A lot of it comes down to what feels right, new, exciting, engaging, and not so much what is theoretically optimal.

I prefer the simple config and the selection-first editing model (best writing on this: https://kakoune.org/why-kakoune/why-kakoune.html). After talking to other Vim users who had a hard time adjusting to Helix, I think I must have used Vim in a pretty Helix-like way to begin with — selecting first. I never could get used to vim motions where the target text is not visualized.

Hx is batteries included. Nvim requires installing lots of plugins that do not inspire confidence - descriptions ridden with emojis, impossible to know who maintains what. Too many vectors leading to possible compromise.

1. hx is fast to start, and fast to use, it looks pretty too 2. the defaults are pretty good, i added a few bits and bobs, but customizing hx is not a way of life for me. emacs and neovim had me stuck in endless improvement loops... 3. tui works great on remote servers, it is nice to have the same setup on my mac, linux, and server. sure other editors does that too but also hx. 4. i got all the lsp i need. arguably getting my languages.toml setup was more fiddly than I wanted. In practice I found getting the setup right on other editors also was a bit of a chrore though.

Nice! I didn't know about:

    :reset-diff-change

I've been using

    git checkout -p

But doing this inside Helix is much more convenient.

I still prefer Neovim but I'm glad to see Helix getting some love recently. Hopefully it continues to do well.

Last I checked they still don't have a plugin system., I bet they'll see a jump in popularity when that gets going.

I think the plugin system is close, the author is just busy with other things before doing the final push to get it merged.

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

Still haven't found a way to delete the current line in Helix (even if the current line is blank; "xd" will delete the current non-empty line, but will delete two lines if the current line is empty).

    x Select current line, if already selected, extend to next line extend_line_below

    X Extend selection to line bounds (line-wise selection)

Just use X.

Ah, so Xd will always delete the current line and e.g. X2xd will delete 3 lines. Still not as nice as dd/3dd like in vim, but at least I don't have to keep extra state in my head.

I just use “d” for empty line.

Annoying, isn't it? I am running a trivial fork to change the `x` behavior on an empty line.

https://github.com/helix-editor/helix/pull/4847

I think I will be using that patch; thanks!

Interesting. What happens when you open a file in the yazi pop-up? Does it create a buffer in Helix?

I'm not sure OP configured it this way, but it's possible. For example, yazelix gives you that functionality.

I do it using `nvim --server`, but not sure Helix can do it. https://neovim.io/doc/user/remote.html

"There are a lot of emerging supply-chain attacks, and I simply don't like the idea of installing tens of plugins to Vim/Neovim to make the editor usable." This is exactly what I’m concerned about.

this used to be a valid selling point for helix until neovim added LSP and treesitter support to the editor, which happened years ago. modern neovim is quite capable out of the box.

I'm really not well experience in Vim vs Helix, but could one say that Helix is more like if Vim was in visual mode by default, and stayed in it even after an action?

And so, could (Neo)Vim be configured to work more like Helix?

See helix.vim on GitHub

Interesting that every time Helix comes up, someone just has to mention Neovim. You never see Emacs or Helix users do that the other way around. Almost as if they’re personally offended.

Isn’t the reason more benign.

Neovim exist to improve upon concepts in Vim (easier plugin development with Lua).

Helix exists to improve upon concepts in Neovim (need for less plugins, more out of box functionality).

Not that surprising to be honest.

Helix is more similar to Neovim than Emacs and Helix is newer and less popular than Neovim, so people are predictably curious on why they should choose Helix over Neovim.

Vin/Neovim is one of the most popular editors in the world, Emacs and Helix are far from that.

emacs is far from that? that seems mistaken

Here's just one survey: https://survey.stackoverflow.co/2024/technology#1-integrated... showing how unpopular Emacs is. It has a lot of mindshare among greybeards but very few people actually use it.

Jeez, do you know what projection is?

> Interesting that every time Helix comes up, someone just has to mention Neovim.

that apparently includes helix's creators, considering neovim is mentioned both on its website and in its repository's readme

I've really tried using Helix, I've forced myself to learn the flow, I'm even efficient in it by now. But I came to the realization, that while the reversed flow is easier to implement and easier to learn, it's just slower to use. I came back to Vim, and eventually to Zed (in Vim mode).

Co-incidentally, I started learning neovim (via lazyvim) this week. I just gave Helix a try, and I think the selection and motion logic is much more natural to me.

I might try to learn this instead of neovim for a while.

Never really considered supply chain attacks with neovim, but that is a bit worrisome as I use around 15 plugins. I can see why the author switched to something with a reduced attack surface.

I need the ability to run the current file with a shell script / program. Like Vim offers with :!whatever %

Last time I checked Helix did not offer this. Has this changed?

These have been available since mid-2022:

  :insert-output Run shell command, inserting output before each selection.
  :append-output Run shell command, appending output after each selection.
  :pipe, :| Pipe each selection to the shell command.
  :pipe-to Pipe each selection to the shell command, ignoring output.
  :run-shell-command, :sh, :! Run a shell command

The placeholder for the current file is %{buffer_name} (not as bad as it looks, the command line has tab completion for basically everything).

I give a try of helix today, it's really good design editor, but mising many quick operations of vim like y2$, dw.

They are not missing: y2$ is 2xy, dw is just wd.

For those looking beyond Helix, Kakoune and Neovim, Vis is a lightweight and elegant option, worth a look.

It looks interesting, but I'd put it more in the "simple, but simple != easy" category.

Helix is built around showing you what will change before you commit the change which reduces the accidental change problem that vi, vim, neovim has.

In the case of Vis' regex based commands, helix will let you do a regex based find, remove certain matches, then commit a regex replace.

Is the “accidental change” really that much of a problem if you can undo with a single keypress?

Yes, since most accidental changes aren't noticed until well after they are made.

I tried helix and I liked it but it’s not usable for me without the ability to author plugins

Plugins, coming to a release near you: https://github.com/helix-editor/helix/pull/8675#issuecomment...

Or you could check out the branch where the plugin system and the community's plugins have been kicking around for a while now

Reply on news.ycombinator.com