Hacker News

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!

>we have people like Thiel and Luckey misinterpreting Tolkien

Could you provide an example / be more specific about this?

Blame Perl. As far as I can tell, they started it.

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.

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.

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

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)

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.

The latter is pretty easy to vibe-patch in:

https://github.com/burke/helix/pull/1

With time I actually came to get accustomed to it and to enjoy my files not reloading automatically with Claude Code changes.

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

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

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/

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.

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

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.

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.

But how is ki like rust, and why is that significant? Helix is pretty rad, even if what you say is true.

Wait, helix has a file explorer now? The lack of one has been preventing me from using it more

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

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

it's either ragebait or smth. Helix is not C++ and never would be it. Vim is C, Neovim is C++

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?

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

Have you tried Emacs' Extensible Vi Layer ("Evil" mode)? My muscle memory switched almost seamlessly from Vim to Emacs with Evil mode

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

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/

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.

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.

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

> 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

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

Agreed. But very useful for quick editing, and easier to install than vim on Windows.

why? There is LSP support included. Pretty usable. Of course this is not fully IDE, but I don't expect this from "editor"

I can’t believe it still doesn’t have plugins. That’s crazy. They’ve been working on that for so many years.

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.

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

I open that pull request from time to time to check the progress. Want them to release it so bad

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.

Neo/vim does this with community and built-in “text objects”.

https://neovim.io/doc/user/usr_04/#_text-objects

https://ki-editor.org/docs/introduction

Cool. Any information on what will be included in the next release?

this doesn’t address all your concerns but i use “X” to select lines above:

[keys.select] X = "select_line_above"

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.

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

My local build of helix is 20MB, did you use the suggested flags on the install guide page?