Live data from Hacker News

Helix Editor 25.07

helix-editor.com

101–110 of 167 posts

Re: Helix Editor 25.07

#101
post #55

Earlier quoted context omitted.

111mb is bloat apparently in a time where storage is in the terabytes.

I mean a base Mac Mini in 2025 comes with 256GB of storage. Some storage is still damn expensive. But regardless, if someone were to only ever installing Helix on their system, you might have a point. But you probably want to install many applications and if every applications starts wasting storage, you will soon run out of space.

Yes, but 111MB is .04% of 256GB. Install a hundred such "wasteful" apps and you're up to a whole 4% of that storage.

Re: Helix Editor 25.07

#102
post #45

Earlier quoted context omitted.

> minimal https://github.com/helix-editor/helix/issues/6187

I agree. I can't fit this on my hard drive. I've had this 386 for 30 years. Why should I have to upgrade it just for some text editor?

Same. Or — just an idea — maybe it is time to kickstart an adapter so that we can plug a 386 into a LGA 1700 socket? A little underclocking, instruction translation, voltage conversion and presto.

Re: Helix Editor 25.07

#103

Earlier quoted context omitted.

But there is only so much room for muscle memory or context to switch between. I tried Helix for a while, got used to it and I really liked it, especially the noun verb order being different from vim. Seeing what you have selected before performing the action. But for me the problem is that vim is everywhere I go or will eventually end up. All my servers have vim. Every server I need to randomly debug has vim or vi.…

> But there is only so much room for muscle memory or context to switch between. People can learn to juggle plates while riding a unicycle. They can play prog rock on two-necked guitars. A handful of keybindings is like a drop in the bucket for what our nervous system is capable of encoding.

Fear and doubt are mighty enemies. “Did I make the right choice?” haunts us all.

But when exploration is (temporarily at least) an end in itself, trying a new sword, moat-digging technique, or trebuchet mechanism is inherently satisfying.

Re: Helix Editor 25.07

#104
post #86

Earlier quoted context omitted.

111 MB for a text editor is acceptable? I mean I get it, "we" are getting conditioned to it, but...

Long forgotten the times back in the days during the Great Editor Wars when Emacs was shunned as an acronym for "Eight Megabytes And Constantly Swapping". The youth of today ...

Emacs binary download page pointed me to Windows, but for comparison:

141MB: emacs-30.1-nodeps.zip

75MB: emacs-30.1-installer.exe (better compression? Contents seem similar)

27MB helix-25.07-x86_64-windows.zip

So there's still an Emacs distinction, it seems

(*not that these size differences matter in practice -- helix's "bulk" is all in compiled language grammars, each of which is not loaded unless you use the language.)

Re: Helix Editor 25.07

#105

Helix is great and includes a lot of stuff out of the box (file pickers, syntax highlighting, linting etc) without any configuration or installing plugins (contrary to vim or neovim). I would definitely use it but the main disadvantage is that some keybindings work differently than vim. I understand that the keybindings may be better that the vim ones but after years of using vim I expect "x" in normal mode to delete…

Helix is adding a Scheme for programmable configuration.

With programmability, you can have a lot more state and contextual behavior. We get this kind of fine-grained stuff in Emacs with repeat maps, transient maps, heuristic DWIM behavior, state tracking per-buffer etc.

As LLMs lower the cost of having that 8th or 9th language, you can expect programmable tools to float up in the market.

Re: Helix Editor 25.07

#106
post #84

Helix is great and includes a lot of stuff out of the box (file pickers, syntax highlighting, linting etc) without any configuration or installing plugins (contrary to vim or neovim). I would definitely use it but the main disadvantage is that some keybindings work differently than vim. I understand that the keybindings may be better that the vim ones but after years of using vim I expect "x" in normal mode to delete…

I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_…

surprised helix doesn't support the . key - is that incompatible with its interaction model somehow?

Re: Helix Editor 25.07

#107
post #55

Earlier quoted context omitted.

111mb is bloat apparently in a time where storage is in the terabytes.

I mean a base Mac Mini in 2025 comes with 256GB of storage. Some storage is still damn expensive. But regardless, if someone were to only ever installing Helix on their system, you might have a point. But you probably want to install many applications and if every applications starts wasting storage, you will soon run out of space.

Almost all the size is language grammars, which are optional and removable. Some distros like Alpine make them separate packages.

But for desktop use, I think it's a good default to have everything "just work" out-of-the-box, because 110mb is nothing for typical developer machines.

Re: Helix Editor 25.07

#108
post #106
post #84

Earlier quoted context omitted.

I'm totally fine with (re)learning new tools, but having given Helix a solid try found the noun-verb model worse; the visual feedback is fun but distracting, particularly when you're moving around reading code. For it you give up things like repeating edits easily (bound as '.' in Vim). There's also a statefulness to Helix's model that isn't present in Vim; whereas in the latter I only have to care about where I _am_…

surprised helix doesn't support the . key - is that incompatible with its interaction model somehow?

Yes, its model is that you make a selection and then act on it. After the action happens there's nothing selected. The editor can't infer your intent in making the selection, so there's no reasonable notion of repeating the last edit. You can separately repeat the last motion or last action, but not the whole edit---which of course isn't as useful.

Helix would _ideally_ like you to tell it ahead-of-time everywhere you're going to make an edit by selecting all the edit points with multiple cursors, without a great option to fire edits on the fly. Ironically I found this worse for visual feedback when making larger edits---where it's most needed---because there are usually edits happening off screen, instead of only at the point of the cursor (where the latter can be easily repeated).

It ends up feeling less interactive and more like I'm using a batch editor due to this, which (I think?) was not its intention.

Re: Helix Editor 25.07

#109
post #47

Earlier quoted context omitted.

I used vim for a few years about 15 years ago, yes. It's not that it's difficult for me, it's that it's unnatural for me. Different people's minds work differently.

It is wild to me that you could use vim for years and not like the modal style. To each their own, I would have bounced to emacs.

I went from vim to emacs and used that for a few years, then moved to VS Code for the next 10 years or so. It's showing its age a bit lately, so I'm sure I'll try another one soon, which is why I looked at Helix. But I'm very glad there are very different editors for very different types of minds, just like how there are different ways to indent/format code. Programmers do not have one-size-fits-all minds, and we shouldn't design anything assuming they do/should. (Looking at you, Golang.)

Re: Helix Editor 25.07

#110
post #57

Earlier quoted context omitted.

Omg. Vim keybindings is the single blocker for me to try helix. It means that it's possible to add vim support for Helix but they don't want to?

Sure, why wouldn’t it be? Plenty of programs have Vim keybindings. The challenge is matching the behavior perfectly 1-1.

This is where vim keybinds fall short every time. I do appreciate the effort, and have zero expectations about a one to one match, but the moment I do something out of habit and an editor doesn’t do what I expect, in “vim mode”, it breaks the illusion.
Post reply on HN