How I'm Using Helix Editor

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

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

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

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

> Expreg (teeesitter expand region)

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

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.

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

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.

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.

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.

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

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.

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

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.

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

> 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

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.

Jeez, do you know what projection is?

For how long have you been using Emacs before?

    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.

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 just use “d” for empty line.

See helix.vim on GitHub

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.

Helix's editing model is better.

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

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.

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

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

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.

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

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.

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