Live data from Hacker News

Helix Editor 25.07

helix-editor.com

71–80 of 167 posts

Re: Helix Editor 25.07

#71
post #55
post #45

Earlier quoted context omitted.

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

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

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

Re: Helix Editor 25.07

#72
post #39

Congrats! I am happy for helix but i don't think it's a good fit for me. I use Neovim. It does what i want it to do. It's one of the best available options. But, i am not completely satisfied with it. I personally want an editor with following: * Modern codebase. Written from scratch. * VIM Keybindings: I have muscle memory of Vim. I would like to use Vim Keybindings in my editor. I don't want to use any other keybin…

> I have muscle memory of Vim. I respect the preferences of others but I think that most people overfit for muscle memory. I've switched OSes/editors/IDEs many times in my career. Every time, the first day or two I feel like "This is the worst fucking thing ever, I can't even type God damn it I want to set the computer on fire and become a farmer." But... that passes. After a couple of days, I have new muscle memory…

personally i just find verb noun editing a tiny bit more fun than noun verb.

you craft an incantation that either does everything right or backfires. there’s no feedback while said incantation is being constructed.

practically, noun verb is much better of course.

Re: Helix Editor 25.07

#73
post #8

Earlier quoted context omitted.

> All I want is ... Understandable, for sure, but the number of users who want their own "simple" addition means it gets overwhelming pretty quickly. Helix has deferred work on most extra functionality until after implementing a Scheme extension language. Once that's done, adding features might be as simple as installing a plugin.

Authors are free to do as they please, but as an entitled member of the peanut gallery…aren’t there already enough small configuration languages? Seems like a distraction when there are already hundreds of schemes, Lua, Janet, etc.

I don't know if this is still the case but they were leaning towards Steel.

Relevant Github comment: https://github.com/helix-editor/helix/issues/10389

Steel: https://github.com/mattwparas/steel

Re: Helix Editor 25.07

#74
I'd love for Helix to implement a "Kakoune mode". I develop on Windows at work, where Kakoune is not ideal, so Helix seems like it'd be a perfect fit, except I can't get over the keybindings. Its keybinding philosophy encourages verbosity instead of Kakoune's terseness, which bothers me more than it probably should, and as far as I can tell its keymap configuration isn't yet powerful enough to emulate Kakoune well.

Vim's inconsistent keybinds and behavior are what pushed me to Kakoune — which I find has more consistent and elegant bindings and behavior — in the first place, and Helix feels like a step backwards on that front.

Re: Helix Editor 25.07

#75
post #16
post #10

Earlier quoted context omitted.

It looks very interesting and I'd love to support it, but editors that must be modal are difficult for me to use, personally. Editors that are not modal can be made modal, but can modal editors be made non-modal?

I wouldn't want to go from modal to non-modal. In fact, I have a hard time editing in web browser textareas and Google Docs because of the muscle memory of vimlike keybindings and how I've associated them with tactile keyboards. (Smartphones and tablets don't give me this problem since they feel different, but laptop/desktop Google Docs editing throws me for a loop.) Once you learn, modal is the way to go. It feels l…

My comment was after having learned and gotten very good at vim about 15 years ago and used it primarily (via neovim) for at least a while, probably a few years, before moving to emacs, and finally VS Code. I still use vim for quick edits on the command line. I know how to edit modally, it just feels unnatural for me.

Re: Helix Editor 25.07

#76
post #37

Does it do code folding yet?

Here is the forum post that convinced me NOT to continue getting into Helix. It says all I need about the project health. And given the development since then, I am more confident that it’s a bad horse to bet on. https://github.com/helix-editor/helix/issues/1840#issuecomme...

I don't see the problem. It's a great result: (paraphrasing) "people arguing about whether code folding is useful or not is pointless. we're going to do it eventually but not right now." What's wrong with that?

Re: Helix Editor 25.07

#77
post #37

Earlier quoted context omitted.

Here is the forum post that convinced me NOT to continue getting into Helix. It says all I need about the project health. And given the development since then, I am more confident that it’s a bad horse to bet on. https://github.com/helix-editor/helix/issues/1840#issuecomme...

I've never used Helix and I likely never will, so I've got no horse in this race. But code folding, seriously? I'd be totally against it. It's yet another editor feature that ties your source code to tooling . It allows you to write too large and too many functions, while keeping the code readable to yourself . Source code should be readable (mostly) independently of tooling. It should be readable when printed to pap…

Could not agree more with everything you said. I hate code folding because it leads to giant functions and blocks that are way too big, but because of the folding people don't have to look at it and scroll (which if they did, they would be much less inclined to write and ship such shit in the first place). Same with type inference. It's almost no effort to write out the type, and it's eminently readable. With type inference, it's not at all obvious. I usually get "well you can just hover over it with the IDE and it will tell you the type." I don't want to have to hover over stuff just to see the type! Not only is that a major downgrade from the previous state where it was just "String some_str" or whatever, but having to pause and grab the mouse and move it over to the variable is majorly disruptive to reading and requires me to use a mouse (which I don't normally use). Also, I use neovim, not whatever IDE you use and think everyone else must use.

I likewise thought the final response linked to was great. It was straightforward and to the point.

Re: Helix Editor 25.07

#78
post #72

Earlier quoted context omitted.

> I have muscle memory of Vim. I respect the preferences of others but I think that most people overfit for muscle memory. I've switched OSes/editors/IDEs many times in my career. Every time, the first day or two I feel like "This is the worst fucking thing ever, I can't even type God damn it I want to set the computer on fire and become a farmer." But... that passes. After a couple of days, I have new muscle memory…

personally i just find verb noun editing a tiny bit more fun than noun verb. you craft an incantation that either does everything right or backfires. there’s no feedback while said incantation is being constructed. practically, noun verb is much better of course.

I think noun-verb is worse; I'm unsure where the idea comes from that Helix's (or Kakoune's) editing model is better. Bear with my short rant. :-)

I don't want or need pre-emptive visual feedback on every keystroke, because it's a tool I use every day. I want an editing language that allows me to develop a mental model of it, so that I can _avoid_ round-tripping most edit actions visually. The primary advantage of the Vi editing language has never been speed (though that tends to be a secondary one), it's that it saves you from thinking about editing. Visual feedback also adds noise; it's especially distracting when you're moving around reading code. It's not an automatic win except when you're learning. Finally, if I really need it, I'm using a modal editor! I can simply switch into visual mode for complex edits. That's the modal solution.

And in exchange for (ime, annoying) visual feedback I have to give up things like the repeat last edit '.' key, and operator pending mode (see :omap), and more... which isn't palatable to me. Of course, everyone works differently; different strokes. But it's not obviously better, in a lot of ways.

I _am_ envious of the complete default configuration Helix has. Though it seems like that's planned from Neovim in the near future, alongside multicursor (filed under 'super macros'), looking at their roadmap.

Re: Helix Editor 25.07

#79
post #55

Earlier quoted context omitted.

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

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

The editor is 10mb. It's the grammar files that are represent the bulk, and those are optional.

And yes. Complaining about 100mb nowadays is ridiculous. You probably have larger logfiles sitting somewhere in disk doing nothing right now, regardless of your OS.

Re: Helix Editor 25.07

#80
post #47

Earlier quoted context omitted.

Have you ever used a modal editor? It takes the smallest bit of brain training to adapt, but feels more logical for long form coding. I spend a lot more time reading code than writing. Having more tools to grep/highlight/move text in one mode is quite productive.

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.
Post reply on HN