[HN Gopher] Helix: A post-modern text editor
___________________________________________________________________
Helix: A post-modern text editor
Author : doener
Score : 317 points
Date : 2026-03-06 23:53 UTC (23 hours ago)
(HTM) web link (helix-editor.com)
(TXT) w3m dump (helix-editor.com)
| canistel wrote:
| Do have a look at the second question in the FAQ :).
|
| I do find Helix very impressive. I remember the Python LSP
| working without any configuration whatsoever.
|
| However, I have vim muscle memory built over 25 years of use. I
| already struggle switching between Emacs and vim (or its
| equivalents) - for example, after a period of vim usage, I would
| press ESC repeatedly in Emacs, three of which are enough close a
| window. While Helix borrows modal editing from vim, it introduces
| subtle (and meaningful - I have to admit) variations, which
| unfortunately wreaks havoc with my muscle memory. Maybe the worst
| part about muscle memory is that unlearning is almost impossible.
| My dilemma, not Helix's fault...
| dilawar wrote:
| I have been using an ergonomics keyboard for a while and find
| it impossible to go back to normal keyboard.
|
| For the last two weeks, I was forced to work at a normal
| keyboard. After initial pain for one day, I got back to typing
| at normal speed. Without losing my comfort with the ergonomic
| one. I can now just context switch. It wasn't easy though.
|
| Perhaps you will also become comfortable with both vim and
| helix after the initial struggle?
| lorenzohess wrote:
| Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My
| muscle memory switched almost seamlessly from Vim to Emacs with
| Evil mode
| canistel wrote:
| I have in fact. I use Emacs for org-mode and markdown.
| Because of some reason, evil and org-mode did not mix well -
| for me. There is evil-org, which I did not try.
| weinzierl wrote:
| _" However, I have vim muscle memory built over 25 years of
| use."_
|
| Me too and it took a view attempts but I'm on Helix now and
| don't regret it. Once you are over the most prominent
| discrepancies like dd and G it's an uphill battle.
| imjonse wrote:
| agreed, it wasn't more than a few days/a week. The real
| annoyance is if you use other coding environments too which
| do not have hx bindings (VScode, Google Colab) and have to
| constantly switch between hx and vim keys. Zed has had very
| good hx keybindings support for a few months now so this
| became less of an issue.
| korantu wrote:
| I think Zed editor has helix phylosophy of supporting LSP out
| of the box while having exact vi bindings if it is important.
|
| [1] https://zed.dev/
| imjonse wrote:
| It actually has Helix bindings as well which makes the
| investment in Helix not that risky anymore. I use both.
| kombine wrote:
| Neovim supports LSP out of the box since version 0.11. It
| requires very little configuration to enable and configure
| it.
| kleiba wrote:
| _> I would press ESC repeatedly in Emacs, three of which are
| enough close a window._
|
| You can configure every combination of keystrokes in Emacs -
| just bind M-ESC ESC to something harmless (such as, e.g., not
| function at all).
|
| One possibility would be the following line in your ~/.emacs
| file: (global-set-key (kbd "M-ESC ESC")
| 'keyboard-quit)
| ATMLOTTOBEER wrote:
| Is this kind of comment not just a tautological rebuttal to
| any criticism of emacs
| canistel wrote:
| Thank you for mentioning this. I do have something similar...
| (global-unset-key (kbd "ESC ESC ESC"))
| Panzerschrek wrote:
| I tried using it once by compiling it from sources. Even a
| release build is several hundred megabytes in size, which I find
| pretty wasteful. After a little investigation I found, that it
| has many plugins in form of a shared library, and each of them
| has pretty huge size, presumably because the whole Rust standard
| library is statically linked.
| whytevuhuni wrote:
| Interesting, although I checked and on NixOS the binary is just
| 29MB. It was statically linked, with just libc left as dynamic.
|
| I think 29MB is still huge for a terminal text editor, but
| nevertheless not "hundreds".
| f311a wrote:
| Language grammars are ~200-250MB though. They are in a
| separate folder, and often they are all bundled to support
| all the languages. Some of them are HUGE.
| .rwxr-xr-x 4.6M aa 6 Mar 21:52 ocaml-interface.so
| .rwxr-xr-x 4.6M aa 6 Mar 21:52 rpmspec.so .rwxr-
| xr-x 4.9M aa 6 Mar 21:52 tlaplus.so .rwxr-xr-x
| 5.1M aa 6 Mar 21:52 ocaml.so .rwxr-xr-x 5.1M aa
| 6 Mar 21:52 c-sharp.so .rwxr-xr-x 5.3M aa 6 Mar
| 21:52 kotlin.so .rwxr-xr-x 5.4M aa 6 Mar 21:52
| ponylang.so .rwxr-xr-x 5.5M aa 6 Mar 21:52
| slang.so .rwxr-xr-x 6.1M aa 6 Mar 21:52 crystal.so
| .rwxr-xr-x 6.8M aa 6 Mar 21:52 fortran.so .rwxr-
| xr-x 9.2M aa 6 Mar 21:52 nim.so .rwxr-xr-x 9.5M
| aa 6 Mar 21:52 julia.so .rwxr-xr-x 9.9M aa 6
| Mar 21:52 sql.so .rwxr-xr-x 16M aa 6 Mar 21:52
| lean.so .rwxr-xr-x 18M aa 6 Mar 21:52 verilog.so
| .rwxr-xr-x 22M aa 6 Mar 21:52 systemverilog.so
| Panzerschrek wrote:
| That's exactly what I found. Why these files should exist
| at all? Some other IDEs just have a bunch of highlighting
| rules based on regular expressions and have a folder of
| tiny XML grammar files instead of a folder of bloaty shared
| libraries.
| homebrewer wrote:
| Because it's far more reliable to use proper parsers
| instead of a bunch of regular expressions. Most languages
| _cannot_ be properly parsed with regexes.
|
| Those files are compiled tree-sitter grammars, read up on
| why it exists and where it is used instead of me poorly
| regurgitating official documentation:
|
| https://tree-sitter.github.io/tree-sitter
| f311a wrote:
| Funny enough, they are less than 10MB when compressed. I
| guess they could use something like upx to compress these
| binaries.
|
| The whole Linux release is 15mb, but it uncompresses to
| 16MB binary and 200MB grammars on disk.
|
| Why do we need to have 40MB of Verilog grammars on disk
| when 99% of people don't use them?
| homebrewer wrote:
| That would waste CPU time and introduce additional delays
| when opening files.
|
| They could probably lazily install the grammars like
| neovim does, but as someone who doesn't have much faith
| in the reliability of internet infrastructure, I'll
| personally take it...
|
| Just ran `:TSInstall all` in neovim out of curiosity, and
| the results were predictable:
| ~/.local/share/nvim/lazy/nvim-treesitter/parser
| files 309 size 232M
| /usr/lib/helix/runtime/grammars files 246
| size 185M
|
| If disk space is important for your use case, I guess
| filesystem compression would save far more than just
| compressing binaries with upx. btrfs+zstd handle those
| .so well: $ compsize
| ~/.local/share/nvim/lazy/nvim-treesitter/parser
| Type Perc Disk Usage Uncompressed Referenced
| TOTAL 11% 26M 231M 231M
| $ compsize /usr/lib/helix/runtime/grammars Type
| Perc Disk Usage Uncompressed Referenced TOTAL
| 12% 23M 184M 184M
| f311a wrote:
| I mean, they could decompress it once when using a
| language for the first time. It will still be fully
| offline, but with a bit uncompressing.
| e12e wrote:
| If this is a concern, why not compress at the filesystem
| level?
| Panzerschrek wrote:
| For real parsing a proper compiler codebase (via a
| language server implementation) should be used. Writing
| something manually can't work properly, especially with
| languages like C++ and Rust with complex includes/imports
| and macros. Newer LSP editions support syntax-based
| highlighting/colorizing, but if some LSP implementation
| doesn't support it, using regexp-based fallback is mostly
| fine.
| small_scombrus wrote:
| My local build of helix is 20MB, did you use the suggested
| flags on the install guide page?
| hrmtst93837 wrote:
| Those huge plugin files result from Rust duplicating libstd
| into each plugin at link time when crates are built as cdylib
| or staticlib, and you can prove it with cargo-bloat or by
| inspecting DT_NEEDED and symbol sizes with readelf -d and ldd.
|
| If you control the build, force shared std linking with
| RUSTFLAGS='-C prefer-dynamic' and crate-type = ['dylib'] so
| host and plugins share libstd and accept the need for matching
| toolchains, or switch to a different plugin model like
| compiling to WASM and running modules with wasmtime or exposing
| a small C-ABI shim into a single shared runtime, and use strip
| plus LTO for quick size wins.
| dalanmiller wrote:
| Love `hx`, vim never really clicked for me and the batteries-
| included nature of helix is one of its best selling points.
| Curiositry wrote:
| This has been my main editor for prose and code for a few years
| now (Sublime Text -> Atom -> Vim -> Helix). Overall, it has been
| great. Many LSPs work almost out-of-the-box, and my config is a
| fraction the size of my old .vimrc.
|
| Surprisingly, it didn't take that long to update my Vim muscle
| memory. Days or weeks, maybe? However, I still have mixed
| feelings about modal editors in general, and most of my gripes
| with Helix are actually about modal editors and/or console
| editors in general.
|
| Code folding is a feature I'm still waiting for.
| wilkystyle wrote:
| Curious to hear your gripes about modal editors! I'm a long
| time Emacs user (traditional keybindings, not evil-mode), but I
| also started using Vim in parallel a little over a decade ago.
| I feel very proficient/productive in both, regularly using many
| of Vim's more advanced motions and functionality. I generally
| love the power and composability of Vim text objects, and
| definitely experience the benefit of using them. But there are
| some times where I am doing things like many small edits within
| a line where rapidly changing modes for all of the edits starts
| to feel cumbersome.
|
| For Emacs, I use multiple cursors and a treesitter-based plug-
| in for incrementally expanding or reducing the selection by
| text objects. I also have a collection of my own helper
| functions for working with text that make my non-modal Emacs
| approach still feel very comparable to the power of
| manipulating text in Vim.
|
| Curious to hear if your issues with modal editing are similar.
| cassepipe wrote:
| My main gripe with modal editors is that they still use the
| Escape key to go back to normal mode even though Escape was
| chosen for historical reasons (used to sit much much closer to
| the home row on older Unix Keyboards) In Linux and MacOs I can
| change it with just one gui setting but it's still annoying how
| everyone went with it. It's not mentionned in most vim
| tutorials. According to a vim reddit poll, at least half of the
| users are just using Escape where it is now instead of one of
| the alternatives. This is beyond me, it feels like someone
| inventing glasses in order to see better but everyone settled
| on cast iron frames.
| andrewl wrote:
| Cassepipe, it's not a great default for sure. What do you
| have yours mapped to? I mapped jj to return to normal mode
| and also save my file. So, as I'm typing, I just hit jj, the
| jj vanishes, and this command is run:
|
| <Esc>:w<CR>
|
| I could just have it escape instead without saving.
|
| If I hadn't chose jj it would have been ff, which is also
| always under an index finger. I do wish I'd been clued into
| the idea when I started with Vim instead of two years later.
| cassepipe wrote:
| I find the jj/jk hack a bit too clever for my taste. I just
| map CapsLock to Escape system-wide because it also unlocks
| quick escaping for shells vi-modes too and I realized that
| actually Escape is a really nice key to have around in a
| lot of UIs to get out/go back/cancel what you are doing. I
| also like that it's a simple gui setting away (or registry
| key editing in windows).
|
| I either put CapsLock where Escape sits or use both shifts
| simultaneously (one cancels it) but even then I almost
| never use it. The rare times I need to type a lot of
| uppercase together is generally code in vim and visual
| selection + gU does the job.
|
| The point of my comment was not to shill for a particular
| solution though but for the vim community to acknowledge
| the problem publicly instead of it being some insider
| knowledge you discover in a random internet comment six
| months into fighting vim (if you haven't dropped out yet)
| zargon wrote:
| What key would be a good candidate as a default though?
| Imagine the memes for exiting vim if you needed a
| modifier to get into normal mode. Caps lock is truly a
| useless key and should be escape anyway.
| dunham wrote:
| As someone who cut their teeth on a sun "programmer"
| layout, I really need control to be in that position. I
| might try mapping the vestigial control key to escape
| though. Or maybe the hack that dtj1123 describes (tap is
| escape, hold is control), if I can pull that off on
| macos.
| sodapopcan wrote:
| <ctrl-[> always works out of the box which is less of a
| stretch than esc.
|
| I do jk as I always find a roll easier on the fingers
| than a double-tap jj or kk. You could also use space
| provided you aren't using one of those distros that bases
| its identity on the spacebar.
| gigatexal wrote:
| Yea for me capslock is a systemwide esc for me. Works
| great.
| dtj1123 wrote:
| I have caps remapped to esc when tapped, and ctrl when held.
| Takes perhaps a weekend to get used to, but once the muscle
| memory is there it feels incredibly comfortable and natural.
| dev-ns8 wrote:
| Is this macro mapped in vim or OS level? Sounds
| interesting.
| cassepipe wrote:
| Last time I checked, on all OSes you need to install some
| third-party software alas. Hopefully I am wrong now.
| CorrectHorseBat wrote:
| I configure it in the firmware of my keyboard with QMK
| cassepipe wrote:
| I have hesitated many times to set this up but I don't want
| to get used to something that I cannot set up in less than
| 30 seconds on a new machine.
|
| Not having Escape where CapsLock sits on a new machine
| already makes it infuriatingly unusable already :)
| gpvos wrote:
| Which tool can do that kind of wizardry? I've seen either
| but not both.
| katsura wrote:
| On macOS I use Karabiner-Elements to do the exact same
| thing. Also, my config is only applied in terminals,
| everywhere else the original functionality is kept. So,
| I'd say it is quite flexible.
| sodapopcan wrote:
| I mean... if people don't mind reaching, so what? I
| purposefully don't remap my leader key, although I don't have
| many leader mappings so it's not like I'm reaching for it
| constantly.
| cassepipe wrote:
| I mean if people don't mind having cast iron glasses, sure
|
| No but really, vim's paradim that you should go back to
| normal mode constantly. With the current situation you get
| posts on the vim subreddit asking/telling you about insert
| mode editing commands. You might as well use Emacs at that
| point, at least it would be the intended workflow
| grayrest wrote:
| I map caps to ctrl and do ctrl-[ to get to normal mode. The
| main reason is using Vim bindings in other editors where Esc
| can get intercepted by other bindings but ctrl-[ has always
| worked everywhere.
| cassepipe wrote:
| My opinion is that going back to normal mode is too
| important a key to be a key combo, and a weird one at that
| (is it [ or ] ?). I am pretty sure you can get used to it
| but we humans get used to anything really, doesn't make it
| good. My pressing on CapsLock happens at a subconscious
| level. Quick edit and then punctuate with CapsLock with the
| pinkie. Some random key combo is not acceptable.
|
| But again my point is that the default sucks. You probably
| learned a about Ctrl + [ while looking online for
| alternatives after realizing the default sucked
| nurettin wrote:
| I haven't opened a text editor to code in months and probably
| won't need to anymore. Goodbye vim and intellij, nice knowing
| you. It was a good while it lasted. Glad I haven't invested
| decades into emacs like some of my colleagues.
| kristiandupont wrote:
| I wrote my own modal-mode extension for vscode/cursor because
| couldn't get the VIM-ones to function like I wanted. During that
| time, I thought that I should look into Kakoune and Helix as
| those seemed to represent a true iteration on the paradigm. Being
| able to see what you're about to change makes complete sense, as
| does the "multi-cursor first" approach.
|
| However, after a few weeks, I ended up rewriting things to be
| more classic VIM-like after all. This might have just been muscle
| memory refusing to yield, I am not sure. One thing I remember
| though, was that the multi-cursor+selection approach only really
| helps when you can see everything you're about to change on the
| screen. For large edits, most selections will be out of the
| scroll window and not really helping.
|
| I still haven't written it off completely, though with AI I
| increasingly find myself writing more prose than keywords and
| brackets, so I am not sure it's going to feel worth it.
| eviks wrote:
| > only really helps when you can see everything you're about to
| change on the screen
|
| Which is still a net positive over the alternative?
| hou32hou wrote:
| > For large edits, most selections will be out of the scroll
| window and not really helping.
|
| That's why the Ki editor has a feature called Reveal Cursors
| (https://ki-editor.org/docs/normal-mode/space-menu#-cursor-
| re...), which is specifically made to solve this issue
| klibertp wrote:
| > One thing I remember though, was that the multi-
| cursor+selection approach only really helps when you can see
| everything you're about to change on the screen. For large
| edits, most selections will be out of the scroll window and not
| really helping.
|
| In Emacs, there's an mc-hide-unmatched-lines command that
| temporarily hides the lines between the ones with cursors. This
| makes multiple cursors usable with up to a screen-height number
| of items (being able to place cursors by searching for a regexp
| helps).
|
| I agree, though - MCs are most useful for simple, localized
| edits. They're nice because they don't require you to mentally
| switch between interactive and batch editing modes, while still
| giving you some of the batch mode benefits. For larger or more
| complex edits, a batch-mode tool ("Search and replace",
| editable occur-mode in Emacs, or even shelling out to sed) is
| often a better choice.
| bayesianbot wrote:
| Tried it again few days ago. I kinda get that currently you can
| only use AI on Helix through LSP, but on top of that it does not
| have auto-refreshing files when changed outside - makes it really
| hard to work with external AIs, as I'm just constantly worrying
| if I'm editing a stale file.
| small_scombrus wrote:
| I know it's not a proper fix, but helix does have `:reload` and
| `:reload-all` commands
|
| I have reload-all bound to Ctrl-r
| dcre wrote:
| Same!
| vaylian wrote:
| > you can only use AI on Helix through LSP
|
| How do other editors do this, if they don't use LSPs? Helix
| specifically choses LSP as _the_ integration mechanism (in
| combination with TreeSitter) for supporting different
| programming languages, because it is a language-agnostic
| protocol and therefore only needs to be implemented once. Is
| there some established AI-agnostic protocol /interface? I don't
| think MCP would work here?
| small_scombrus wrote:
| > Is there some established AI-agnostic protocol/interface?
|
| AFAIK no
| logicprog wrote:
| ACP?
|
| https://agentcommunicationprotocol.dev/introduction/welcome
| potro wrote:
| ACP Agent Client Protocol
| https://agentclientprotocol.com/get-started/registry
| beaker52 wrote:
| This is a distinctly Zed solution - trying to move the
| agent experience into the editor, rather than just giving
| the agent an interface with which to control and read from
| the editor.
|
| Not only do the most popular editors have little-to-no
| incentive to implement it (they're more interested in
| pushing their own first-class implementations, rather than
| integrating those of others), it's much more work to
| integrate the evolving agent experience into the IDE than
| it would be to provide IDE integration points for the
| agents themselves.
|
| So, I think this project would have been much more
| successful if it had been more focussed on keeping the
| agent and IDE experiences separated but united by the
| protocol, instead of trying to deeply marry them. But
| that's not in line with Zed's vision and monetization
| strategy.
|
| It won't be long before the big players start to release
| their own cloud-based editors. They'll be cloud-based
| because the moat is wider, and they'll try to move coding
| to the cloud in the way that Google Workspaces moved docs
| to the cloud. Probably with huge token discounts to capture
| people. If you squint, you can already see this starting to
| happen with Claude Desktop, which runs its agent loop on
| the cloud (you can tell because skills appear to need to be
| uploaded).
|
| Notably, Microsoft, with VSCode and GitHub have a web-based
| editor advantage in this space, but no models.
| spudlyo wrote:
| It's not just Zed, Emacs has has a thriving ACP
| implementation in agent-shell[0], and allows for some
| very cool integrations[1]. There are a fair number of
| other clients[2] as well.
|
| [0]: https://github.com/xenodium/agent-shell
|
| [1]: https://www.youtube.com/watch?v=HJQ86HuSIJI
|
| [2]: https://agentclientprotocol.com/get-started/clients
| yammosk wrote:
| The second half of this is spot on. The now is making
| IDEs that can integrate with agents, not the other way
| around. Soon the Claude and Codex will do that for us on
| their hosts and the argument is it will save sending the
| context up.
| nikita2206 wrote:
| Just watching filesystem for file changes and updating the
| in-memory view of the file on any change? This isn't really
| relevant to MCP, though one option is to provide a different
| tool to the AI agent for file modifications, which would make
| modifications through the file editor itself.
| vaylian wrote:
| > Just watching filesystem for file changes
|
| This is non-trivial, if you want to do it efficiently. On
| Linux you can set up an inotify listener for individual
| files, but not for entire directories. This also breaks
| down if you are working with data on non-local drives.
| clouedoc wrote:
| With time I actually came to get accustomed to it and to enjoy
| my files not reloading automatically with Claude Code changes.
| dayjah wrote:
| I was feeling this pain also; so I switched my workflow to
| watching file changes with lazygit, and then switching to helix
| to make small tweaks.
|
| Another option you may want to try is mux
| (github.com/coder/mux). It wraps the LLM in a nice interface
| which has the ability to do line/block comments on changes by
| the LLM that then goes goes into your next prompt. It's very
| early stage though: v0.19.0.
| g947o wrote:
| GitHub Copilot, Claude Code and Codex provide fairly good IDE
| integrations. They don't just edit files behind your back. They
| actually edit the files you have in the IDEs using editor APIs
| and even show you a nice diff view. This way you never have
| content that is out of sync. I find this approach very usable
| and appealing.
|
| On the other hand, many of the AI tools and their companies
| think that you should completely ditch IDEs for CLIs only,
| because "nobody needs to write code anymore". Some of them even
| stopped maintaining IDE extensions and go all-in in CLIs.
|
| (I call that complete BS)
| buzzerbetrayed wrote:
| I don't even open a text editor anymore 90% of the time.
| Seems clear to me that IDEs, in the traditional sense, don't
| really have a place in the future of software creation. They
| might morph into something that does, but definitely not in
| their current form, imo.
| satvikpendem wrote:
| If you actually want to engineer properly and review the
| code rather than pushing out vibe coded slop PRs, then IDEs
| absolutely do have a future.
| mbrumlow wrote:
| > If you actually want to engineer properly.
|
| I think this statement is misguided, and potentially
| comes from a lack of experience in getting AI coders to
| produce quality.
|
| Proper engineering does not come about from the tools you
| use or how you use them. Proper engineering has always
| come from thought, and reasoning, it never was about the
| act of coding. It always was about the systems thinking
| and expressing the goals and desires that matched the
| requirements.
|
| IDEs were never needed to properly engineer and in the
| days of AI will become increasingly less important.
|
| Tools for planning, reviewing, and commenting on code are
| the future. The necessity to edit actual code is coming
| to an end.
| satvikpendem wrote:
| Yes, that's what I said, I'm contrasting properly
| engineered AI code to vibe coded slop AI code, not that
| human written code is inherently better engineered.
| yonatan8070 wrote:
| I've noticed that Codex usually uses the native editing tools
| and shows me a diff, but sometimes it just sidesteps that and
| does a cat > file << EOF, so I need to rely on Git diffs to
| tell what it did.
| MrJohz wrote:
| > This way you never have content that is out of sync.
|
| They can definitely go out of sync, particularly if something
| that isn't the editor or the AI changes the code (e.g.
| running shell commands or opening the file in a different
| editor and making changes there). I've had a whole load of
| issues with VSCode where there's been spurious edits all over
| the place that show up again even if I try and revert them,
| because every time the AI makes an unrelated edit, VSCode
| tries to reset the file to the version it thinks exists and
| _then_ play the AI 's edits on top.
| burke wrote:
| The latter is pretty easy to vibe-patch in:
|
| https://github.com/burke/helix/pull/1
| lukaslalinsky wrote:
| I really wanted to like Helix, it's a great software, works out
| of the box. I dedicated energy to unlearn my vim habits and learn
| the helix way. I'm now able to use it fairly effectively, but
| eventually I just came to the conclusion the bindings are done
| the way they are due to simpler implementation, not simpler user
| interface. I'm back to neovim for small updates and zed in vim
| mode for larger code editing.
| exidex wrote:
| Have you tried Ki Editor[0]? It seems to be more into direction
| that you are looking for. It is not as mature as the rest of
| the editors but the editing model is definitely an improvement
| from ux perspective
|
| [0]: https://ki-editor.org/
| rfmoz wrote:
| Vis editor [0] also has multicursor and powerful sam's
| structural regular expression
|
| [0]: https://github.com/martanne/vis
| rgoulter wrote:
| Hadn't heard of this. So I looked at the docs for Ki.
|
| I see the "Why Ki?", and then it has this:
|
| > Being first-class means that it is not an extra or even
| sidekick; it is the protagonist.
|
| Eh.
|
| I find it quite off putting.
|
| I guess my expectation is that someone enthusiastic enough to
| write a text editor with a value proposition of "it's got
| good tree-sitter-based navigation" would want to discuss why
| they thing syntactic selection is neat.
|
| Seeing cliche LLMisms doesn't signal the same level of care
| to me.
| exidex wrote:
| Having been in the community for some time, it is just how
| the authors are, very enthusiastic about the wording. They
| like to come up with some wild terms explaining different
| behaviors and reasoning behind those behaviors, like
| "positional coherence" or "behavioral asymmetry", and the
| term "kimmunity" to reference to ki editor community. On a
| surface level, sure, it looks LLM generated, but I would be
| very surprised if they used LLM to generate that sentence.
| I choose to look at the actual meaning of the content and
| what they are trying to do differently
| bulbar wrote:
| To me, what you describe is a red flag.
|
| For example, that doesn't sound like they will take
| feedback from the community serious.
| exidex wrote:
| To some extend that is true for any opinionated piece of
| software. But that is a beauty of opensource don't use it
| if it doesn't match your idea of how that software should
| look like
| hou32hou wrote:
| It's not generated by LLM, it was actually my idea, but
| grammar-corrected by LLM, but you are not wrong either, the
| docs are really subpar in a lot of ways, and not clearly
| explaining why is one of them, and of course, the
| potentially cringey sentences too, someone complained the
| docs read like a Vogue magazine before lol
| beefsack wrote:
| The different bindings vs Vim was actually what stopped me
| using it. I really really wanted to love it and love a lot of
| the motivation and principles behind it, but unlearning decades
| of muscle memory is an absolute nightmare.
| itsn0tm3 wrote:
| There is also evil-helix [0] a helix fork with vim bindings.
| Maybe that's something you would enjoy :)
|
| [0] https://github.com/usagi-flow/evil-helix
| deafpolygon wrote:
| at that point... use vim? genuinely asking. what does this
| get you?
| lukaslalinsky wrote:
| Not having to deal with neovim plugins is a HUGE win. Using
| neovim with plugins feels like using a rolling Linux
| distro, you never know what breaks next. That's what I use
| zed, personally. It's the best modern vi-like editor, in my
| opinion.
| xigoi wrote:
| > Using neovim with plugins feels like using a rolling
| Linux distro, you never know what breaks next.
|
| You can just... not update them.
| lukaslalinsky wrote:
| They don't have LTS releases, there is always a bug
| somewhere and the bug fix includes a number of features,
| if not new dependencies.
| GCUMstlyHarmls wrote:
| Yeah I _always_ see this "issue" with Neovim and its
| almost entirely user-cultural, installing big blobs of
| plugins, updating to edge every day and some kind of
| jones's pressure.
|
| These days you can probably install mini.vim to get
| basically every paper cut fixed (eg extra "surround
| objects", aligning text, plugin manager etc), a theme, a
| few other assortments to taste and park your plugins at
| known commits or include them in your dotfiles and its
| ... fine. I haven't updated my plugins in probably 6
| months and when I do I update them selectively only if
| there is actually a reason to do it or the changes are
| very minor.
| itsn0tm3 wrote:
| I just use neovim ;) Just commented to inform. But I can
| see the benefit of something like evil-helix, very limited
| setup being needed and getting features like LSP out of the
| box ...
| imjonse wrote:
| what do you mean it does not have a simpler user interface? I
| found the combo of hx for quick edits/terminal work and Zed
| with hx bindings for everything else great.
| linsomniac wrote:
| I'm a very long time user of vi/vim, and I've gotten tired of
| maintaining vim configs. I've gotta have my LSPs and
| treesitters. I decided I wanted to move away from self
| maintenance and use something opinionated.
|
| But, I found helix a little _too_ opinionated. In particular,
| when you exit and go back into the file it won 't take you back
| to where you were. I decided I'd start using helix on my "work
| journal" file which is over 20K lines and I edit somewhere
| towards but not at the end (done is above the cursor, to do and
| notes are below). Also, I _NEED_ hard line wrapping for that.
|
| Helix doesn't seem interested in incorporating either of those,
| which were "must haves" for me.
|
| So I set the LLMs on it and they were able to make those
| changes, which was pretty cool. But I ended up deciding that I
| really didn't want to maintain my own helix fork for this, not
| really a plus over maintaining my vim config.
| Groxx wrote:
| > _eventually I just came to the conclusion the bindings are
| done the way they are due to simpler implementation, not
| simpler user interface_
|
| This was my general feel from using it for a bit too. I don't
| think that _necessarily_ makes it a worse result (there 's a
| form of user-facing consistency in 'this implements like that',
| it's just a bit meta), but it's one of the things that
| constantly pushed me away a bit. Some semi-common actions just
| didn't feel ergonomic, even after a couple weeks. (not implying
| that vim is a bastion of perfection, of course)
|
| That said, I _HIGHLY_ recommend people give Helix and /or
| Kakoune it a try. The different mental model is immediately
| compelling in some ways, and on balance I think it's a better
| approach. It's just that you have to weigh the details that
| might not work for you against all the other IDEs out there
| that have a heck of a lot more stuff already built for them...
| and it may mean you don't keep using them. Or you'll be
| thrilled with the end result.
| small_scombrus wrote:
| I desperately wish Helix would support virtual text (code folder,
| markdown links just showing the text when not selected), but the
| default keybinds and the way that selecting and editing text work
| just works too well in my brain to go anywhere else
| kubafu wrote:
| My default editor for the past couple years. Love the simplicity,
| speed, and the fact I can navigate comfortably with just the
| keyboard. Plus Elixir LSP integration is a cherry on top.
| rrr_oh_man wrote:
| Love the FAQ > Post-modern?! It's a
| joke. If Neovim is the modern Vim, then Helix is post-modern.
| > Is it any good? Yes.
| jiehong wrote:
| A new version should arrive this month or the next one. I think
| it's worth trying it again then
| vaylian wrote:
| Cool. Any information on what will be included in the next
| release?
| theusus wrote:
| Using agents to edit code. And Helix doesn't support live update
| of files. This is the reason it's not my first choice.
| pjmlp wrote:
| Up voting, only because it is another native option, away from
| Atom started trend to ship Chrome alongside every single "modern"
| application.
| haxfn wrote:
| Vim is like C, Helix is like C++ and Ki Editor is like Rust.
|
| "Within C++, there is a much smaller and cleaner language
| struggling to get out."
|
| Helix carries a baggage of ideas from Vim. It does not have
| consistent and transferable keybinds. It does not have
| composition of ideas:
|
| You can move to the next line in the buffer editor with `k` but
| to move down to the next line in the file explorer you have to do
| `ctrl+n`?
|
| Vim is like C, Helix is like C++ and Ki Editor is like Rust.
| efnx wrote:
| But how is ki like rust, and why is that significant? Helix is
| pretty rad, even if what you say is true.
| ministryofwarp wrote:
| I'm puzzled by the idea that positional constant is good for
| key bindings. How does the machine I ssh to know my keyboard
| layout or whether I am using a input with a related positional
| concept? (I suppose I should say I was puzzled by it, and now I
| am puzzled why this idea is back yet again.)
| hou32hou wrote:
| > How does the machine I ssh to know my keyboard layout
|
| Why does it need to? If you are using say, Dvorak, you can
| just pick the keyboard layout by pressing `*` (a keybinding
| which is not affected by the chosen keyboard layout)
| ministryofwarp wrote:
| The machines and coworkers I have have no idea what I am
| using locally if they don't watch my typing, it could be
| QWERTZ or Turkish-F it could be a chorded keyboard.
|
| Going backwards to layout makes no sense to me. They then
| can't tell me what to type, we get to fight about env
| defaults, etc.. And for what? If your composition is any
| good it is approaching the abstract of code so looking at
| your hands and some visual feedback is of little value as
| it traverses the whole context.
| hou32hou wrote:
| It's good at least in my case because I switch between
| Dvorak (Corne) and Qwerty (laptop's keyboard) all the
| time, without positional keymap, I would have to develop
| two sets of muscle memory
| ministryofwarp wrote:
| The effective freedom to choose keyboards like Dvorak
| relates directly to the privacy of a remote vi not
| breaking the privacy layer of this abstraction. Do what
| we do because the servers won't be updated or we will
| specifically lock their choices, etc..
|
| After a few years of trying to get along directly in
| local pair programming or similar with people with local
| largely insane keymaps I decided to make use of fences
| and privacy making good neighbors and I don't want those
| fences ruined.
|
| Even without my intended uses for this abstraction,
| positional habits is the first step of getting people out
| of the crib, a crib is easy to sell a start in but not a
| place to retire.
|
| Helix OTOH looks good.
| worksonmine wrote:
| > You can move to the next line in the buffer editor with `k`
| but to move down to the next line in the file explorer you have
| to do `ctrl+n`?
|
| I've never used Helix, but this exists in vim too, but it the
| autocompletion, because in that context hitting k would type k.
| Makes sense right? I'm guessing hitting k in Helix file
| explorer has a similar use, maybe searching?
| eviks wrote:
| Nope, you'd then do Ctrl+K, not N
| worksonmine wrote:
| (Neo)Vim omnifunc? Ctrl+k does nothing in my setup,
| probably your config or a plugin. Or am I misunderstanding
| what you mean?
| eviks wrote:
| Yes, a slight misunderstanding, I only meant that the
| fact that _K_ types in insert mode doesn 't mean you move
| to _Ctrl+N_ to replicate its functionality, you should
| still maintain the same position ( _K_ )
| worksonmine wrote:
| Sure, but [n]ext and [p]revious are common in the TUI
| world and which one makes more sense is debatable.
| There's decades of history behind the choice and while I
| prefer j/k I wouldn't call n/p wrong.
| eviks wrote:
| Yes, it's an very common mistake, there is also decades
| of history behind fixing it. But the debate here is _not_
| j /k vs [n]ew file/[p]rint file, but about the
| _inconsistency_ of using one logic in navigating lines of
| text in an editor vs another in navigating lines of text
| in a file list
|
| > consistent and transferable keybinds
| worksonmine wrote:
| I'm pretty sure next and previous are older than new file
| and print file both of which have little use in this
| context. You could also see it as navigating lines of
| text vs navigating results in a list (ie search in
| less/vim) if you want to be pedantic. In (Neo)Vim <C-j>
| in insert mode inserts a new line below the current and
| <C-k> inserts digraphs. N/P are not necessarily
| inconsistent.
| n_kr wrote:
| Wait, helix has a file explorer now? The lack of one has been
| preventing me from using it more
| christophilus wrote:
| It does, but iirc, it's only an explorer and isn't able to
| delete, rename, or create.
| hbbio wrote:
| Been playing with agent strategies, vibe coding this:
| https://github.com/hbbio/rc that uses helix by default
|
| Using it already (the granular branch) but it's far from
| stabilized...
| rw_panic0_0 wrote:
| it's either ragebait or smth. Helix is not C++ and never would
| be it. Vim is C, Neovim is C++
| pineaux wrote:
| I agree. Helix is more like ruby on rails.
|
| I will try ki editor
| redrobein wrote:
| People really need to stop making analogies and saying what
| things really are.
| seg6 wrote:
| Helix has been my main editor for a few years now. I went from
| Sublime Text to VS Code to Neovim, and eventually landed on
| Helix. I've shipped a lot of code with it, and my config is still
| under 50 lines, even with a few extra keybindings to emulate some
| Vim bindings I still find useful. I didn't find the keybindings
| particularly hard to get used to, and switching back and forth
| between Vim and Helix has never been much of an issue when I've
| had to work on a system without `hx`.
|
| For the curious:
| https://github.com/seg6/dotfiles/blob/1281626127dfbf584c2939...
| rgoulter wrote:
| Helix is a really nice editor. I use it as my go-to for when I'm
| in the terminal environment.
|
| For sufficiently complex manipulations, I find the "selection-
| action" ("motion-action") to be more intuitive than "action-
| motion". Even with vim, I'd often like making use of visual mode.
|
| I think the main limitation to this that I believe is it's
| probably a bit slower for quick + frequent edits compared to vim.
| bulbar wrote:
| I want an editor that's built around language entities.
|
| "Move to end of the scope" or "insert after this expression" and
| similar.
|
| The overlap between languages should be large enough to make this
| feasible.
| srik wrote:
| Neo/vim does this with community and built-in "text objects".
|
| https://neovim.io/doc/user/usr_04/#_text-objects
| zer wrote:
| These are great. I really have come to love this little
| plugin that extends and creates a/i textobjects:
|
| https://github.com/nvim-mini/mini.ai
| vaylian wrote:
| Helix has built-in Tree Sitter support.
|
| > "Move to end of the scope"
|
| You can select the current syntax object under the cursor with
| alt+o and expand the selection to the enclosing syntax objects
| with further presses of alt+o. This moves you automatically to
| the end of the selected syntax object. You can use alt+b to
| move to the beginning of the selected syntax object.
|
| > "insert after this expression"
|
| Select the expression and after that you can use regular
| commands like a and p.
| org3 wrote:
| https://ki-editor.org/docs/introduction
| ctenb wrote:
| Worth noting: the plugin system is steadily approaching maturity
| and will probably be integrated and released soonish(tm)
| https://github.com/helix-editor/helix/pull/8675
| rw_panic0_0 wrote:
| I open that pull request from time to time to check the
| progress. Want them to release it so bad
| swiftcoder wrote:
| I was really hoping this would have a postmodernist aesthetic
| qudat wrote:
| I learned about kakoune from helix. I played with both of them to
| figure out which one I preferred and ended up choosing kakoune
| for simplicity. It's a fantastic editor and my cfg is 50 LoC
| which is just fine for me.
|
| As long as helix doesn't add a plugin system I think both are
| superior to neovim. Neovim defaults are just awful. I hate that
| quickfix and loclist are so close to being useful for pickers but
| it just misses the mark and now there's lock in on some terrible
| impl because we don't want to break backwards compatibility. The
| select -> action model is superior.
|
| Having an opinionated editor just makes so much sense. We don't
| need 10 different picker implementations.
| jqbd wrote:
| I want to like it, it's much snappier than vim, but:
|
| I hate selecting lines up. Down xxx is fine. But to go up I have
| to do x alt; v k. This would be shift+v k in vim.
|
| I often use } { to navigate the file in vim. In hx it's ] p which
| is very awkward for the fingers. The auto selection makes it hard
| to read once I use ] p.
|
| Pasting does not behave like vim, often have to click o first
| then p.
|
| I have to often press ; to unselect just to be able to insert
| after I navigate to a character with F f t T.
|
| Can't copy from documentation. Can't create files in the
| explorer.
|
| It feels like much more work to use hx keybindings than vim.
|
| What I love:
|
| Hints whenever you press a key allow you to learn keybinds
| quickly.
|
| Very quick.
|
| Built in search, file picker, lsp rust out of the box.
| shinypants wrote:
| this doesn't address all your concerns but i use "X" to select
| lines above:
|
| [keys.select] X = "select_line_above"
| irusensei wrote:
| I love it but the search and replace sequences are too
| complicated and then I have no idea how to unselect multiple
| lines without specifying a line.
|
| My vim muscle memory is too strong and stubborn.
| fnordlord wrote:
| I'm in a similar boat. It's become my primary editor but I
| still open VSCode everytime I need search-and-replace or an
| easy git-blame.
|
| For unselect, if I'm understanding correctly, ; will unselect
| with your cursor at the end of the selection, Alt-; will
| unselect and move your cursor back to the beginning.
| g947o wrote:
| This.
|
| I tried it out for a few days, and I cannot justify spending
| time on this when I am already very productive with
| vim/VSCodeVim. Helix is nice in many ways but not worth
| switching over
| discommentbad wrote:
| Helix deez nuts
| level87 wrote:
| I've used Helix as my main editor over the past few years, I love
| it, but the speed of development is quite slow.
|
| Would love to see some AI related plug-ins when the plug-in
| system is finally released.
| buzzerbetrayed wrote:
| I can't believe it still doesn't have plugins. That's crazy.
| They've been working on that for so many years.
| marcosqanil wrote:
| I love helix. Incredibly snappy and minimalistic but still having
| every feature a serious IDE needs, out of the box.
| shnpln wrote:
| I have been using helix for over a year now. I love it.
| para_parolu wrote:
| I was very enthusiastic about helix since it rethinks some of vim
| complexity. But lack of plugins makes it just an editor for small
| files only that I can quickly start on server and doesn't not
| make it suitable for serious work.
| feelamee wrote:
| why? There is LSP support included. Pretty usable. Of course
| this is not fully IDE, but I don't expect this from "editor"
| para_parolu wrote:
| Just to be clear: it's not suitable for me to do work using
| this editor. There are many features lacking that makes me
| more efficient. In case of vim that is solved by a few
| plugins. It's not about being IDE but rather about being well
| fitted tool. I wish I would only need LSP but it's not enough
| for my work.
| linhns wrote:
| Agreed. But very useful for quick editing, and easier to
| install than vim on Windows.
| para_parolu wrote:
| That's a perfectly fine usecase. But all systems I work with
| have vim installed by default anyway. And vim handles big
| files better than helix (not sure why)
| messh wrote:
| ohh Ki and Helix on the front page today... it's a good day! :)
| assbuttbuttass wrote:
| I really want to like Helix, but I wish the developers paid more
| attention to performance, or were more receptive to outside
| contributions. Helix can really chug, even on small files, and
| the perception in the community seems to be "it's written in Rust
| so therefore it's blazingly fast :rocket-ship-emoji:"
| lofatdairy wrote:
| This is only tangentially related, but regarding:
|
| >>Post-modern?!
|
| >It's a joke. If Neovim is the modern Vim, then Helix is post-
| modern.
|
| It's interesting that postmodern is so often used by people,
| perhaps less familiar with the arts and the humanities, to mean
| "an update to modern" or a progression thereof. They use it in a
| strictly literal sense, eschewing the precise meaning of the term
| they're referencing by mere addition of discontinuity as
| incremental difference.
|
| Obviously, there's little impact to this. The term is hardly
| degraded by engineers advertising to other engineers. It looks a
| touch unread, but then again we have people like Thiel and Luckey
| misinterpreting Tolkien, so again it's hardly the most egregious
| example. I guess it just jumped out to me because I was hoping to
| see something creative truly postmodern.
| the_hoser wrote:
| Blame Perl. As far as I can tell, they started it.
| vaylian wrote:
| Source: https://www.wall.org/~larry/pm.html
| wk_end wrote:
| Except that, from that talk, Larry clearly has some idea
| about what the term postmodernism means in art & culture
| and isn't just using it to mean "modern++".
| ctmnt wrote:
| That jumped out at me too the first time I ran into Helix
| making this joke, and I was also disappointed to find that they
| meant modern++.
|
| That said, I'm not sure I agree with your assessment that it's
| wrong, exactly. Postmodernism did indeed follow modernism and
| come into being as a reaction to modernism. So I think
| "postmodernism" has a naive and original sense of being "what
| follows modernism". Decades (so many at this point!) of
| discourse have added layers to that and undermined it and
| generally made it more complex. But the underlying meaning of
| the term remains.
|
| (If your instinct is to respond with arguments about how works
| not limited to late 20th century western culture can be
| nonetheless classified as postmodern, I hear you, but the fact
| that the term itself was only coined post modernism remains,
| and is all I'm pointing to.)
|
| Personally, I get more hung up on people using "modern" to mean
| "new". Then to use "postmodern" to mean "more new" while to my
| ears (eyes) it means "dated af" is even funnier and more
| jarring.
|
| Helix, the first editor to not believe in grand narratives.
| Helix, the relativist editor. Helix, now updated with the
| latest from Foucault and Derrida!
| humanizersequel wrote:
| >we have people like Thiel and Luckey misinterpreting Tolkien
|
| Could you provide an example / be more specific about this?
| NERD_ALERT wrote:
| Peter Thiel owns a company called Palantir that designs its
| offices to look like Hobbiton.
|
| It might be less of a misinterpretation and more of an on the
| nose joke about being overtly evil.
| ryanlbrown wrote:
| They are Tolkien fans and yet they are building the devices
| (Palantir, Anduril) which evil will eventually use to
| dominate. Palantir is well-named but tragic that a fan would
| build it. Anduril is poorly-named as it is the sword used to
| combat industrial power rather than represent it.
| debois wrote:
| I switched from neovim because plugins and updates kept breaking
| it, and I never really did feel like I was in control of it
| anyway. Helix does what it does, no fuzz. Never breaks.
|
| You do start to think "can I get helix keybindings in my shell",
| though.
| landr0id wrote:
| I've always used GUIs and had to basically break my brain to
| learn vim keybindings (in Sublime Text) some time ago and the
| helix bindings are just different enough to throw me off. Sucks
| because I would prefer an out-of-box solution that "just works"
| and I'm comfortable in across all my machines for terminal text
| editing.
| __MatrixMan__ wrote:
| At least once a week I daydream about altering nushell so it
| can run helix as a subprocess for handling the editing parts.
| Maybe one day I'll go for it. Until then I'll just to make
| frequent use of the open-in-editor command.
| semiinfinitely wrote:
| I refuse to take a second look at this project until it has a
| functioning plugin system
___________________________________________________________________
(page generated 2026-03-07 23:00 UTC)