[HN Gopher] How I'm using Helix editor
___________________________________________________________________
How I'm using Helix editor
Author : f311a
Score : 169 points
Date : 2025-10-12 15:48 UTC (7 hours ago)
(HTM) web link (rushter.com)
(TXT) w3m dump (rushter.com)
| scuff3d wrote:
| 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.
| mgrandl wrote:
| I think the plugin system is close, the author is just busy
| with other things before doing the final push to get it merged.
| mobilemidget wrote:
| https://github.com/helix-editor/helix/discussions/3806
| dannyfritz07 wrote:
| Interesting. What happens when you open a file in the yazi pop-
| up? Does it create a buffer in Helix?
| jvican wrote:
| I'm not sure OP configured it this way, but it's possible. For
| example, yazelix gives you that functionality.
| dannyfritz07 wrote:
| I do it using `nvim --server`, but not sure Helix can do it.
| https://neovim.io/doc/user/remote.html
| wilkystyle wrote:
| 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_
| dannyfritz07 wrote:
| 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...
| dannyfritz07 wrote:
| Newer nvim is also slowly eating into the plugins needed. There
| is a built in plugin manager, diff viewer, and lsp now.
| petepete wrote:
| Undotree functionality was recently merged in too.
| mi_lk wrote:
| What is nvim built-in diff viewer? Is it just `vimdiff` /
| `nvim -d`?
| dannyfritz07 wrote:
| https://neovim.io/doc/user/plugins.html#difftool
| jatins wrote:
| 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
| maleldil wrote:
| 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.
| k_bx wrote:
| 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.
| evertedsphere wrote:
| > Expreg (teeesitter expand region)
|
| reminds me of combobulate (which i haven't tried but think
| looks cool) but sounds much more light/limited
| ramon156 wrote:
| 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)
| derleyici wrote:
| 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
| f311a wrote:
| 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.
| aidenn0 wrote:
| 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)
| linhns wrote:
| Most people have to work with multiple languages, each of
| them takes around 20 lines, and blanks + comments add up as
| well.
| tpmoney wrote:
| 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.
| ixsploit wrote:
| 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.
| n8henrie wrote:
| 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.
| reppap wrote:
| 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.
| dcre wrote:
| 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.
| cabirum wrote:
| 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.
| nxpnsv wrote:
| 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.
| heldrida wrote:
| 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.
| tiffanyh wrote:
| 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).
| lawn wrote:
| 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.
| adamors wrote:
| Vin/Neovim is one of the most popular editors in the world,
| Emacs and Helix are far from that.
| beanjuiceII wrote:
| emacs is far from that? that seems mistaken
| kgwxd wrote:
| Jeez, do you know what projection is?
| netshade wrote:
| 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
| k_bx wrote:
| For how long have you been using Emacs before?
| netshade wrote:
| 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.
| aidenn0 wrote:
| 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).
| f311a wrote:
| 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.
| johnofthesea wrote:
| I just use "d" for empty line.
| dpc_01234 wrote:
| 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
| jiehong wrote:
| 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?
| bkrein wrote:
| 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.
| rfmoz wrote:
| For those looking beyond Helix, Kakoune and Neovim, Vis is a
| lightweight and elegant option, worth a look.
| bitbasher wrote:
| 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.
| dpc_01234 wrote:
| Helix's editing model is better.
| bitbasher wrote:
| 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).
| ngruhn wrote:
| 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.
| bn-l wrote:
| I tried helix and I liked it but it's not usable for me without
| the ability to author plugins
___________________________________________________________________
(page generated 2025-10-12 23:00 UTC)