Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes on switching to Helix from Vim

jvns.ca

Post reply on HN
Print view View original

171–180 of 242 posts

Re: Notes on switching to Helix from Vim

#171

Post by mackeye »

tejohnso wrote: post #46
jbrooks84 wrote: post #14

Vim is life, no need to change

I just heard of Helix and decided to take it for a spin. I'm not sure why I'd use it instead of Vim. For all the Vim similarity, inverting the do-this-to-that seems like an arbitrary annoyance that I don't understand. Why go from "change this word" (cw) to "I want to change this word, so I'm going to select it first, then change it" (wc). I mean, it's not a big deal, especially if you're not already using Vim, but wh…

(for kakoune, not helix) i've used kakoune daily for almost 2 years now, and i still mix up e.g. `(?but, this is probably less important than the simplicity of the selection first model, as it ties into multisel, etc. a selection is a cursor and an anchor. other keys manipulate the selection(s) in very particular ways, which are predictable. external tools interface easily with the selection format, as it represents cursors and anchors.

each benefit taken alone is quite small, but together they offer kakoune a very lean, predictable design when combined with its use of external programs for tasks like sorts or paragraph reflows.

helix is similar to kakoune w.r.t. the editing model. kakoune has `w` to select the next word (and move the anchor to the start of the next word), and `W` to select the next word (and keep the anchor where it is, so you now have two words selected). helix has `v` to enter visual mode, which is essentially equivalent to caps lock with kakoune --- `vw` in helix is equivalent to `W` in kakoune (i believe).

i think selection first is better, but i think it's fair to prefer vim's style, obviously. but there's certainly ample reasoning, though helix might not explain it thoroughly, because (at least, at one point) they may have expected users to have viewed kakoune previously, and understand its philosophy, as helix is essentially a batteries-included kakoune (and kakoune explains the reasoning quite thoroughly).

Re: Notes on switching to Helix from Vim

#172

Post by llimllib »

mackeye wrote: post #169
llimllib wrote: post #64

Earlier quoted context omitted.

the lack of a `gq` equivalent to reflow a paragraph, which julia mentioned, was the nail in the coffin for me when I tried it. It's a nice project though, I just use that feature constantly

in kakoune, this is ` p |reflow `. which is obviously not as simple as `gq`, but you can rebind this, add things like auto-reflow as you type, etc., rather trivially, and rebind them (and a lot of these types of tools come preloaded as bindable commands). it's some work to set up this type of thing (and it makes perfect sense to use e.g. vim to not need to do that), but i like the composable design, where i can write…

> i can write some configuration to hook a shell command to a bind

is `reflow` a binary that comes with kakoune or something?

Re: Notes on switching to Helix from Vim

#173

Post by andrewflnr »

llimllib wrote: post #172
mackeye wrote: post #169

Earlier quoted context omitted.

in kakoune, this is ` p |reflow `. which is obviously not as simple as `gq`, but you can rebind this, add things like auto-reflow as you type, etc., rather trivially, and rebind them (and a lot of these types of tools come preloaded as bindable commands). it's some work to set up this type of thing (and it makes perfect sense to use e.g. vim to not need to do that), but i like the composable design, where i can write…

> i can write some configuration to hook a shell command to a bind is `reflow` a binary that comes with kakoune or something?

'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.

Re: Notes on switching to Helix from Vim

#174

Post by llimllib »

andrewflnr wrote: post #173
llimllib wrote: post #172

Earlier quoted context omitted.

> i can write some configuration to hook a shell command to a bind is `reflow` a binary that comes with kakoune or something?

'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.

I’m curious about the particular program though! On my Mac it doesn’t exist and I didn’t find it in a quick search

Re: Notes on switching to Helix from Vim

#175

Post by sundarurfriend »

eikenberry wrote: post #71
tasn wrote: post #56

Earlier quoted context omitted.

> Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away I've been using Vim/Neovim for 20 years, but still can't get enough of which-key[1] which I only installed ~6 months ago. 1: https://github.com/folke/which-key.nvim

mini.clue is another good option for this feature in neovim. https://github.com/nvim-mini/mini.clue

The mini set of modules are such a treasure, Evgeni is amazing.

Re: Notes on switching to Helix from Vim

#176

Post by eviks »

weinzierl wrote: post #125
eviks wrote: post #49

Earlier quoted context omitted.

But once helix adds plugins it will be exactly the same because those tens of VSCode plugins provide functionality not present in helix, so will be similarly implemented externally

I hope they will properly sandbox plugins like any modern software should.

That would've been the wasm plugin route, which was rejected in favor of this great emacs feature of using an obscure language, so sandbox are unlikely

Re: Notes on switching to Helix from Vim

#177

Post by eviks »

tasn wrote: post #56
eviks wrote: post #48

> crashes: every week or so there’s a segfault and the editor crashes. ... This doesn’t bother me that much though, I can just reopen it. Strange approach to data loss, since it doesn't have persistent undo, you can't just reopen it to the same editing state? > After using Vim/Neovim for 20 years, I’ve tried both “build my own custom configuration from scratch” and “use someone else’s pre-buld configuration system” a…

> Exactly! Pity this basic contextual help isn't more widespread, every single app that uses a lot of keybind sequences could benefit from it, especially if it becomes a bit smarter and only shows a popup if you don't finish the sequence right away I've been using Vim/Neovim for 20 years, but still can't get enough of which-key[1] which I only installed ~6 months ago. 1: https://github.com/folke/which-key.nvim

Yeah, that's the mortal sin of vim - insisting on shitty unergonomic defaults, requiring every new user waste time recreating a better UI while suffering for years before even the appropriate knowledge is acquired

Re: Notes on switching to Helix from Vim

#178

Post by andrewflnr »

llimllib wrote: post #174
andrewflnr wrote: post #173

Earlier quoted context omitted.

'|' is the command to pipe a selection through a shell command and replace it with the output, so I guess it's just a regular command on their system. You could use any other reflow or reformatting program you had handy. Kakoune in particular is really serious about delegating everything possible to the system.

I’m curious about the particular program though! On my Mac it doesn’t exist and I didn’t find it in a quick search

Honestly, it might have just been a placeholder name for an arbitrary formatter. I vaguely remember old-school unix had a command for that, but none of them seem to be named exactly "reflow".

Re: Notes on switching to Helix from Vim

#179

Post by davvid »

galangalalgol wrote: post #140
neutronicus wrote: post #118

Earlier quoted context omitted.

FWIW, in my (emacs, C++) experience, writing the editor config is a relatively minor part of the yak-shaving required to have jump-to-definition on an actual work codebase. I had to get my project to emit compile_commands.json, get clangd, figure out which things about our build process clangd was not understanding from compile_commands.json and add them in .clangd. All to achieve a level of functionality significant…

Whatever vim is in rhel 8 supports ale. Ale with rust has been great. Go to definition is flawless, all my conpile and clippy errors are underlined as I type and binding a key to ALECodeAction will apply the auto fix if it has one. Usually that is to import whatever I just used, which vscode would do automatically, but still its nice and having vscode use clippy as well as check bogs it down. And ale runs cargo-fmt o…

> upon further thought, I don't like having to move my hand to the arrow keys

ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.

Re: Notes on switching to Helix from Vim

#180

Post by joshcsimmons »

jvican wrote: post #17

I've fallen in love with Helix and now use it for everything. Moved from neovim and VS Code to Helix for the majority of my coding. For me, after trying the Lazy neovim plugin distro and being a long-time vim user, Helix fills a unique need: - It's beautiful (lots of attention to detail) - It's fast (meaning: at no point did I think Helix is slower than it should) - It's hugely ergonomic (each default keystroke reson…

I enjoy helix but don’t write nvim off entirely. I’m not much of a lua dev but llms have proven themselves to be excellent when writing and modifying nvim configs.

IMO that was the biggest motivator to switch was helix’s well put together lsp/lint config.

Post reply on HN