Live data from Hacker News

From VS Code to Helix

ergaster.org

91–100 of 142 posts

Re: From VS Code to Helix

#91
post #84
post #72

> Being a lazy person, I never bothered looking up VS Code shortcuts. Because the learning curve for Helix is slightly steeper, you have to learn those shortcuts that make moving around feel so easy. This doesn't make sense: if you were truly lazy, you wouldn't spend any effort learning a more complicated app, you'd simply not switch! > with a few knobs for minor preferences. I am subject to choice paralysis, so maki…

> And the way out is the same as with vim - just pick someone else who has done it I think the crucial thing here is that most people don't do it, because it works out of the box. You can change any of the keybindings and any of a few hundred settings if you want, but the defaults are good, so you don't have to. My helix config sets the theme and soft-wrap and that's about it.

In what way do vim default keybinds not work vs Helix's since they seem to be very similar (outside of the whole selection-first behavior inversion)?

In general, I agree that good defaults is the way to go, and vim is worse here (except for the theme, helix's default is bad), though again, the alternative isn't a many knobs paralysis, but a better starting set.

Re: From VS Code to Helix

#92

I'm not sure I follow the argument being made here. "I don't like vim as you need to install plugins to make it work" "helix is a dumb editor, so it needs a language server." Then they go and list the number of plugins they install. This seems to argue against what their main point I now use VScode most of the time, however to me its a fancy VIM variant, because I'm so used to vim bindings. I can and do use raw vim,…

The argument doesn't make sense, but I followed the exact same path. For me, Helix is genuinely just more enjoyable to use out of the box, so I felt more motivated to tune it to my liking.

Re: From VS Code to Helix

#93
post #45
post #17

Earlier quoted context omitted.

In helix that's %d (select-buffer, then delete). The selection-then-action design for helix is showing it's difference to vi, which is action-on-movement.

But Vim has visual-mode, which is select-then-action too.

not really, vim's visual mode always extends selection, while in Helix the base mode selects with your base commands so you can act on the selection, but it doesn't extend to the next one. For example, moving by 2 words only selects the 2nd one, not both like in Visual mode. (although in this specific case of selecting everything this difference isn't visible)

Re: From VS Code to Helix

#94
post #72

> Being a lazy person, I never bothered looking up VS Code shortcuts. Because the learning curve for Helix is slightly steeper, you have to learn those shortcuts that make moving around feel so easy. This doesn't make sense: if you were truly lazy, you wouldn't spend any effort learning a more complicated app, you'd simply not switch! > with a few knobs for minor preferences. I am subject to choice paralysis, so maki…

As a long time user of both Emacs (since 18.52) and Neovim and now Helix, I find your last assertion to be false. While it is true that there are many options (though not as many as either Emacs or Neovim), in Helix you cannot write code or install someone else's code to modify your editor. In the past I've spent a good amount of time trying out, integrating, and debugging various packages for Neovim and Emacs. In Helix I might try a new option setting, but the time involved is minuscule compared to what you might spend customizing other editors.

Re: From VS Code to Helix

#95
post #13
post #4

Earlier quoted context omitted.

This is what is keeping me from trying Helix in a serious way. I don't want to learn slightly distinct vi-like keybindings and mess up my muscle memory.

same -- I wish Helix would just have a full vi-compatible mode, it would probably be enough to get me to switch the other thing for me is lack of the GitHub Copilot extension. I am far too used to having tab-complete. there's some effort for Helix extensions to handle this but it's not close to on-par last time I checked

But why then switch?

Re: From VS Code to Helix

#96
post #36
post #27

Helix boast itself as a no config tool, but you have to find a lsp, installl it, edit a toml to activate it. I dont think we can call that "config less". Success would be something like LazyVim but without the nagging of updates each time you open it.

I am whole off the vim (&friends) trend but my 2c- The helix situation is still miles better for up and running asap compared to dancing with files/lua on lazyvim. Just having to refer to docs to install a plugin, writing sane remaps etc eats up time. If you really just speedrun everything under an hour good for you. But for the rest, a lsp is a one package manager install away (even on windows scoop seems to have be…

I agree with all you said. Its an improvment over nvim situation. I still think for common languages like python and markdown lsp should be setup by default. I am not sure if i am willing to forget all the muscle memory I have just yet. Also I miss being able to ZZ to exit my file

Re: From VS Code to Helix

#99
post #2

Helix and other new editors (kakoune comes to mind) always appealed to me because they seemed to have slightly more intuitive approaches to editing than vim, but I just don't think I can ever switch, purely because vim just exists everywhere I need it. It (or vi) is installed on practically every system I ever touch by default, and almost every IDE/editor under the sun supports vim keybinds either natively or via wel…

> I'm sure I could learn to be slightly faster on dvorak/colemak

As near as I can tell, people generally type at similar speeds regardless of layout. If you're aiming for speed typing [1], I can see it making a difference, but chances are you're not going to see much of a difference. I type on an alpha-thumb layout (Hands Down Vibranium, the R key is under my left thumb) on an ergo keyboard. It's like using a fountain pen versus a cheap ballpoint or a nice mechanical keyboard vs a membrane keyboard. The experience is nicer but it's not a fundamentally different process. Being on a weird setup, I was concerned about "what if my keyboard breaks", "what if I'm on a public computer", etc and the solution is just to not forget qwerty. I use the laptop keyboard every other day or so for something short like a comment and it's fine.

What my personal setup does let me do is have my wrists in a neutral position with my arms resting on chair armrests and no active muscle effort. Between the efficient layout and small keyboard I never need to move my hands at all. This means that my wrists are just as well positioned after 12 hours as they are at the start and that's what has been letting my stress injuries recover.

[1] https://www.reddit.com/r/KeyboardLayouts/comments/1lfu1xt/fi...

Re: From VS Code to Helix

#100
post #2

Helix and other new editors (kakoune comes to mind) always appealed to me because they seemed to have slightly more intuitive approaches to editing than vim, but I just don't think I can ever switch, purely because vim just exists everywhere I need it. It (or vi) is installed on practically every system I ever touch by default, and almost every IDE/editor under the sun supports vim keybinds either natively or via wel…

> of always having guaranteed access to qwerty everywhere I go.

You haven't travelled far, obviously.

Post reply on HN