Live data from Hacker News

Helix: A Neovim inspired editor, written in Rust

github.com

261–270 of 321 posts

Re: Helix: A Neovim inspired editor, written in Rust

#261

I gave Helix a try last week and I think there are a lot of things to like about it, but until it supports soft text wrapping for prose documents it's effectively useless to me. I'm not going to bounce back and forth between neovim and helix depending on whether I'm editing code, documentation, or personal notes. The comments on the open issue in Github are not particularly encouraging. https://github.com/helix-edito…

I would say they're pretty encouraging. There's a straightforward path to implement it, and some work is being done on that front.

Re: Helix: A Neovim inspired editor, written in Rust

#262
post #114

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 e…

>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 advanc…

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.

Re: Helix: A Neovim inspired editor, written in Rust

#263

Earlier quoted context omitted.

>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 advanc…

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.

Re: Helix: A Neovim inspired editor, written in Rust

#264

I gave Helix a try last week and I think there are a lot of things to like about it, but until it supports soft text wrapping for prose documents it's effectively useless to me. I'm not going to bounce back and forth between neovim and helix depending on whether I'm editing code, documentation, or personal notes. The comments on the open issue in Github are not particularly encouraging. https://github.com/helix-edito…

I would say they're pretty encouraging. There's a straightforward path to implement it, and some work is being done on that front.

As far as I understand from scanning the PR, there's been more than a year of discussion with no actual progress on a basic (if not in this case simple to implement) feature which is universally available in text editors. Helix looks nice in many ways (I installed it last night and have worked with it on a couple of Rust projects today) but it's clearly more of a research project with potential than current practical tool.

Re: Helix: A Neovim inspired editor, written in Rust

#265

Glad they had the nerve to diverge from the standard vim keybinds. (For those who like the traditional vim binds, I salute you, but I have craved an upgrade for a while now)

I don't particularly like vim keybindings - actually the very fact that they become so much of a consuming hobby for many people speaks to me of real problems with them. But their availability in so many tools aside from vim/nvim makes them very practical, given things as they are. It's a bit like QWERTY. Ubiquitious presence can be more practically useful than intrinsic advantages.

Re: Helix: A Neovim inspired editor, written in Rust

#266

Earlier quoted context omitted.

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

Re: Helix: A Neovim inspired editor, written in Rust

#268
post #255

Earlier quoted context omitted.

What's a list of tabview?

VSCode has a vertical 'subwindow' on the left which list all the opened tabs. I call this 'a tab view/list', I don't know what's the real name. Usually I have between 10 and 20 tab opened, so the tablist is very helpful for navigating between tabs. Unfortunately (AFAIK) the 'fast' editors (vim, kakoune, etc) don't provide such feature. Some have a tree list but not a tab list :-(

Built something like this a few years ago: https://github.com/roblillack/vim-bufferlist

Re: Helix: A Neovim inspired editor, written in Rust

#269
post #215
post #209

Earlier quoted context omitted.

The fastest way to do this in Helix would be `t d`. edit: Paragraph and other object movement/selection is done by the `[`, `]` menu. `]p` for the next paragraph. Surrounds are done by the `m` menu.

Thanks, that's helpful. I get it - so 't' is 'to' and enter is new line. Makes sense. The menu under `[` looks good, but very code-focused and lacking sentences. EDIT: I am finding it a bit weird to have 'go to's as different to movements. There isn't a distinction in vim, which is useful. I'm learning that 'ge' will take me to the end of file, but I can't do 'ged' to delete to there.

You can do vged. Currently ge takes you to the last line, but there is a change planned to take you to the absolute end.

Re: Helix: A Neovim inspired editor, written in Rust

#270

Tried it a few months ago Felt more responsive than neovim/neovide, and out-of-box was great. However, while the selection > verb scheme conceptually made sense, I noticed it took longer to do many basic text editing functions than it would with vim bindings. Perhaps others had a different experience?

I've used Helix since February, and vim for 20 years prior.

For basic edits it's roughly on par now for me (maybe a bit slower?); but then Helix has really neat tree-sitter integration, so as I'm getting more and more used to that, I find myself jumping around code faster and with more precision.

I also never have these moments of fat-fingering a key and then have vim go nuts on me. Like I suddenly deleted half the function and ended up in some mode I've never heard of while doing a recursive recording. ... just mentioning that because I believe (but not sure) that it's because of this selection > verb scheme that I don't ever see that happening in Helix :)

Post reply on HN