Comment by exDM69 | Hacker News Reader

Comment by exDM69 | Hacker News Reader

I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.

Installation was easy and the default configuration is good. Plugging in rust-analyzer still needed a line or two of config file editing, but that should not be necessary for very long. Hint: use `hx --health` to check that all the tools are properly installed and configured (it shows a matrix of programming languages and their associated tooling, with red/green check marks).

My Helix config file is about 5 lines long, but my Vim config is in the hundreds of lines.

I had very little friction coming from Vim and a little bit of Kakoune.

I particularly like the fact that all the important features are built-in and not half baked scripts with unintended side effects (e.g. opening a Makefile in Vim triggers a ftplugin script that messes editor-global config instead of buffer-local, with the default out of the box scripts).

Lots of people are requesting a plugin extension system, which is kinda understandable since every editor seems to have one. But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.

It's still rough around the edges, but good enough for a daily driver.

Thanks to everyone working on the project.

>I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.

Do you have some supernatural ability to quickly (re)learn muscle memory for new keybindings? I’d consider myself a fairly advanced vim user, and it took me literally a couple years to get to the point of fluently using complex navigation/editing commands.

I took a look at the Helix documentation, and while it’s definitely “vim inspired,” it’s different enough [0] that I would have to rewire years of muscle memory to be as productive as I am in vim. There are some very fundamental differences, e.g. the verb/object syntax is reversed in Helix; `dw` in vim is `wd` in Helix. When I want to rewrite a string in vim, I unconsciously type `ci"`; it would take me a long time with Helix to regain that level of fluency.

[0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...

I’ve got the same question. One of the major reasons I invest time into vim is because it’s everywhere and so powerful. If I invested time into learning a different set of keys for an editor that isn’t always available, I wouldn’t be able to leverage that power and fluency all the time, and furthermore, would need to switch back and forth between vim and helix keys

I've switch from years of Vim to years of Kakoune and am now trying Helix. While annoying I find I pick up the right keys fairly quick. A week until I get decent productivity back and a couple of months tops to truly get the hang of it.

I find it immensely helpful that Kakoune and Helix _make sense_. It is also a great boon that there's visual feedback.

Seconding this. I had used Vim for nearly 8 years and felt very comfortable with all the crazy tricks you could do with modal editing but I genuinely felt Kakoune's way of doing modal editing was an improvement so I committed to learning it and it took maybe a month to get comfortable with the new way of editing. I'm really glad I took the plunge because I'm a really happy Kakoune user and I can't think of anything that I miss from Vim.

How does it improve on neovim? Seems to me like slightly different keybindings to do the exact same thing, you're not saving any keystrokes or fatigue as far as I can tell.

It switches from "action selection" to "selection action" which allows you to first select the thing you want to operate on and only then specify what you want do with it. So for example in Vim you may accidentally select too many characters to delete and then you need to redo the command whereas in Kakoune you can adjust the selection before executing the action.

I think one of the best things Kakoune has to offer is that selection mode (visual mode in Vim) is always accessible through <shift><movement> so if I want to select some random number of characters going left, I'll just hold L, or if I want to select all characters until the end of line I'll just press GL whereas gl takes me to the end of line. It makes it so easy to select text.

Finally multicursor, it's so good. I've used Kakoune for over a year now and I haven't had need for macros except for maybe 2 times. I didn't know I needed a multicursor before I had tried Kakoune and I would highly suggest anyone to try Kakoune just for the multicursor experience. It allows you to select a pattern using regex and then operate on the matches simultaneous. Kind of like Vim's "visual block" but on steroids.

selection action is already possible in vim using 'v' or 'V'. But many times, I do want immediate action-operator when I know exactly what I need to operate on. So Kakoune is un-convincing.

>But many times, I do want immediate action-operator when I know exactly what I need to operate on.

This argument doesn't make sense, it's just as fast to type in Kakoune. The order is just different but it makes it possible for you to adjust it when you've either made a mistake or don't exactly know what kind of selection you want.

I know the visual mode in Vim exists under 'v' but the point I was making was that in Kakoune it's more handy and I use it constantly because it's so available, just hold Shift key as oppose typing another letter to enter it. I know it sounds insignificant but I find myself using the visual mode all the time in Kakoune whereas I barely used it in Vim because of that tiny extra effort to enter the mode.

This how I feel about vim too. I’m sure there are editors I would like more but I work on remote servers every day, some of them lightweight, and vim is already going to be on all 500+ of them as part of the OS install.

This was my same impression when trying out helix. Really nice and shiny, but all the shortcuts I've spent time creating over the years are gone and not easily reconfigured.

Don't even try to reconfigure them. Try to learn the editor first as it is.

If you think that's crazy-talk, then imagine someone saying they'd like to learn vim, but they find it hard to configure the shortcuts to be like Eclipse. They aren't wrong, but it also doesn't seem like the right approach to learn vim either.

what does `ci"` do in vim? I'm decent with vim, but it didn't make sense to me - then I tried it and it didn't do anything.

Deletes text inside the nearest quotes and puts you in insert mode. You probably tried it without being inside a quoted string, that's why it did nothing.

Change inside doublequotes. You can also do `ci{` or similar to Change inside curly-braces or `di[` to Delete inside square brackets

Cursor needs to be between double quotes (e.g. inside string literal) for ci" to work. See `:help text-objects`.

ci is "change inner ..."

If we use | to mark our cursor, and you have your cursor inside quote: '"he|re"'

ci" would replace everything inside giving you '"|"' and putting you in insert mode.

cab would aso remove the quotation marks and give you '|'

With ce or cw you'd get '"he"' and cE or cW would give you '"he'

The keybindings are pretty similar, the paradigm change from verb-noun to noun-verb and the multiple cursor paradigm are bigger changes. I got used to it with my brief affair with Kakoune.

The Vim muscle memory will be quite helpful and not a whole lot of unlearning is necessary. hjkl navigation and other familiar concepts are similar in Helix and Vim.

Vim ci" translates to Helix mi"c. After the first key press (m), a help dialog pops up.

hjkl are definitely table stakes for a vim-ish editor, but I also can’t live without 0 and $. Making me move my hand over to find home and end misses the point of hjkl entirely.

I’m just learning helix, but I believe you can move to the end of the line with gl, and i’m sure there’s an equivalent for the beginning.

Is there an alternative for g0, g$ and gj, gk? It will act on wrapped lines like they're separate.

I opened helix to check it for you. Pressed `g` and had a little popup tell me that following with `h` = line start, `l` = line end, `s` first non-blank in line (plus ~15 other options).

My hx doesn't wrap lines, so didn't check `gj` and `gk`.

If you don't wrap lines how do you write text?

Good question, and I don't think my answer will satisfy your needs, but it does mine.

The only long form text that I ever write is in markdown. I do miss the `gq` command from vim, but in general I just do a single line break after every dot. Markdown ignores a single line break in the middle of a paragraph, so it works out okay. I even found it almost convenient to edit text like that because it's easy to move lines around.

In code documentation (which I do a lot of), I have to manually wrap the lines of course (just like anyone else). That's where I miss `gq` the most. :)

After 20 years of vim I decided to try out Helix back in Feb and never looked back, so I guess I can chime in here.

Sure, it took a few days (maybe weeks?) of feeling uncomfortable, but unlike vim, Helix is very approachable. I think you have to be okay with a certain level of feeling uncomfortable if you want to do or learn anything new though. If learning a new editor isn't your thing, then don't. :)

I get this same question a lot when people realize that I use Dvorak layout. Sure, yes, it took time to learn. But I was curious if there was something better for me on the other side. It seemed plausible that there would be, so I gave it a shot. In both cases I have been happy with my investment.

Slightly off-topic: how do you manage using an alternative layout with an editor like vim/Helix? I've been trying to figure out how/if to remap the keys in the editor condig.

If you remap hjkl to your right-hand home row, that could cause a cascade of other remappings. If you don't, you lose basic navigation with hjkl.

I use Dvorak, although I regret the choice to learn it instead of Qwerty. If you don’t remap, and I don’t, then you need to use two hands instead of one to navigate. Not a dealbreaker for me though, since by coincidence the places hjkl ended up on Dvorak that makes navigating with them tolerable.

Instead of qwerty?? Never even considered that a possibility.

I also don't remap anything. It's fiiine. You'll get used to it :-)

> But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.

For me, coming from writing Clojure with Neovim + vim-sexp + vim-fireplace, I would need Paredit and REPL integration.

Paredit is doable with Treesitter, and I'm actually really excited about Helix's Treesitter integration--- every time I write a non-Lisp language, I miss structural editing, so it'll be nice for other languages catch up to Lisp on that front. It doesn't really look like it's quite there yet, though. The built-operations that use Treesitter are spare [0], and while you could implement operations like promote, slurp, and barf with them, you'd have to clobber some register. I don't see at all how you could implement splice without an actual language, since you would need a way to select all siblings of the current node.

REPL integration absolutely needs a plugin language. Unlike the LSP, there isn't a standard protocol for communicating with a REPL, so each language requires its own REPL client. Unless they want to ship a REPL client for every language under the sun, they'll have to provide some way for users to implement their own clients. That said, every time I look at Conjure, they've added REPL clients for more and more languages [1], so maybe it is feasible to have it built into the editor.

[0] https://docs.helix-editor.com/keymap.html

[1] https://github.com/Olical/conjure/

> Paredit is doable with Treesitter

Yes, indeed.

Helix has built-in paredit-like navigation using tree-sitter, the default keybindings are alt-i, alt-o, alt-n and alt-p.

Maybe the Debug Adapter Protocol (DAP) used by vscode will solve the REPL issue in the future. Helix has experimental DAP support but it's still quite rough (but no Clojure DAP server yet).

I think the fact that helix doesn't really need a plugin/extension system is beautiful. It means that it's simple enough to config yet still powerful. Helix smooth out the learning curve in this good way and I hope it won't become complicated and make learning curve as deep as vim/nvim.

My personal deal breaker is the lack of snippets support. Is there a workaround or don't you use snippets at all?

We're working on snippets! It'll take a while longer to get there though.

Reply on news.ycombinator.com