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

From VS Code to Helix

ergaster.org

Post reply on HN
Print view View original

131–140 of 142 posts

Re: From VS Code to Helix

#131

Post by bloppe »

eviks wrote: 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…

Ya, I found the author's justifications for decisions pretty unconvincing.

Of course VSCode keybindings aren't great, but there are excellent Vim keybindings for VSCode, and that's the only thing about Vim that really matters. There are even experimental Helix keybindings for VSCode, and that's the only thing about Helix that really matters. Everything else is just commodified IDE functionality, and VSCode does that best.

And sure, Microsoft is not the kind of company I want to be entirely reliant on. But VSCode is MIT-licensed. There are already tons of forks for various purposes. Switching from VSCode to Helix for this reason is sort of like switching from Chrome to Lynx because you don't like Google. Why not just use Chromium, or Brave? With the level of adoption and support for VSCode, you can bet on well-supported forks popping up the moment Microsoft does anything truly destructive with it.

I mean, if you just want to try out and learn Helix, that's great, but the usability and morality pretense is distracting.

Re: From VS Code to Helix

#132

Post by bloppe »

wuhhh wrote: post #8

I have a similar story but with neovim (and for the same reason as the author; growing unease with big tech). Tried and failed to make the switch a few times but made a concerted effort to stick with it throughout a specific project and now it’s second nature. I found it useful to research idiomatic (n)vim ways of doing things whenever I’d get frustrated or feel I’d be doing something more quickly in VSCode and commi…

Huh. I forgot about %s. I just search for a pattern and replace the first one manually. If there are fewer than ~5 occurrences, I'll just hit `n.` ~5 times and get them all. If there are more, I'll record a macro with `qqn.q`, then look at the occurence count in the bottom right corner (e.g. 50) and hit `50@q` to get them all. Sometimes the replacement text is non-constant, and this method allows for more flexibility with the recorded macro.

Sometimes it's funny to look around and see the strange local minimum of effort you've settled into.

Re: From VS Code to Helix

#133

Post by milliams »

I'd also argue that VS Code is not open source - at least not the version that 98% of people run. If you download VS Code from almost anywhere (and are not using Codium) then you are subject to the licence terms at https://code.visualstudio.com/license which says you may not:

- reverse engineer, decompile or disassemble the software, or otherwise attempt to derive the source code for the software except and solely to the extent required by third party licensing terms governing use of certain open source components that may be included in the software;

- remove, minimize, block or modify any notices of Microsoft or its suppliers in the software;

- use the software in any way that is against the law;

- share, publish, rent or lease the software, or provide the software as a stand-alone offering for others to use.

Re: From VS Code to Helix

#134

Post by tux1968 »

eviks wrote: post #121
tux1968 wrote: post #118

Earlier quoted context omitted.

The details are different, but they're both select-then-act. Admittedly, I've never used Helix, but I don't see how what you've described is a game changer. Surely, at least sometimes, what you want to do is exactly what visual-mode provides: explicitly select a region, using the combined movement of any available operator, and then act on that region.

> at least sometimes Surely you understand the difference between sometimes and all the other times? This is a game changer for all those other times. Otherwise helix has a similar extending selection mode like visual

> This is a game changer for all those other times.

Is it though? I honestly don't understand what the big deal is. The original contention was that the benefit was in offering selection-then-action, unlike Vi. And then when it's pointed out that Vim actually offers selection-then-action as well, there is a new assertion that it's the particular WAY that Helix offers selection-then-action that is key.

To my mind, selection-then-action is provided by Vim if you want it. Maybe it's a few extra keystrokes sometimes, because it's not the default mode, as it is in Helix, but the main concept (ability to think in object-then-verb) is available in both, if that's the way you prefer to think.

Re: From VS Code to Helix

#135

Post by marcyb5st »

jsmailes wrote: 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…

You can try evil helix [1], so your muscle memory won't be affected.

[1] https://github.com/usagi-flow/evil-helix

Re: From VS Code to Helix

#136

Post by eviks »

tux1968 wrote: post #134
eviks wrote: post #121

Earlier quoted context omitted.

> at least sometimes Surely you understand the difference between sometimes and all the other times? This is a game changer for all those other times. Otherwise helix has a similar extending selection mode like visual

> This is a game changer for all those other times. Is it though? I honestly don't understand what the big deal is. The original contention was that the benefit was in offering selection-then-action, unlike Vi. And then when it's pointed out that Vim actually offers selection-then-action as well, there is a new assertion that it's the particular WAY that Helix offers selection-then-action that is key. To my mind, sel…

> I honestly don't understand what the big deal is.

Honestly, you't not even trying to

> To my mind, selection-then-action is provided by Vim if you want it.

Ok, let your mind be content with ignoring the difference that I've just explained. By the way, you can also trivialize vim as "it's just a fewer keystrokes sometimes to do the same as in notepad, what's the big deal?"

Re: From VS Code to Helix

#137

Post by tux1968 »

eviks wrote: post #136
tux1968 wrote: post #134

Earlier quoted context omitted.

> This is a game changer for all those other times. Is it though? I honestly don't understand what the big deal is. The original contention was that the benefit was in offering selection-then-action, unlike Vi. And then when it's pointed out that Vim actually offers selection-then-action as well, there is a new assertion that it's the particular WAY that Helix offers selection-then-action that is key. To my mind, sel…

> I honestly don't understand what the big deal is. Honestly, you't not even trying to > To my mind, selection-then-action is provided by Vim if you want it. Ok, let your mind be content with ignoring the difference that I've just explained. By the way, you can also trivialize vim as "it's just a fewer keystrokes sometimes to do the same as in notepad, what's the big deal?"

> Honestly, you't not even trying to

Why do you think that? I've been listening to what you say. But again, you haven't exactly proven that operating on the single-most-recent movement (which as I understand it, also defines the selection) is the thing that you want to operate on the most often, rather than the convenience of being able to use the flexibility of multiple movements to define a selection.

Anyway, many people do claim that an editor isn't the most important thing, and that thinking takes a lot more time than the operation itself, and that therefore Notepad would often be sufficient. What those people don't really appreciate is the ability to operate on multiple lines at once, not a single selection, but across vast swathes of the text being edited. When your thinking is done, and needs to be applied to every single line of the file, you'd much rather have Vim than Notepad. But in such a case Helix wouldn't offer much, if any, advantage over Vim.

You seem emotionally attached to this in a way that my skepticism provokes, so we can drop the debate. People should use whatever they prefer; no harm done.

Re: From VS Code to Helix

#138

Post by bccdee »

eviks wrote: post #91
bccdee wrote: post #84

Earlier quoted context omitted.

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

Oh, vim's keybindings are fine. But vim is missing LSP, completion, file pickers / fuzzy finding, surround operations, easymotion jumps, and displaying buffers in the tab line. Those need to be added with plugins.

That's what's clogging up my init.lua, not keybindings. I'm glad I can adjust keybindings in both helix and vim. It's the plugins I resent, and with helix, these features are bundled in.

Re: From VS Code to Helix

#139

Post by lcnPylGDnU4H9OF »

allknowingfrog wrote: post #50
jsmailes wrote: 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 switched from Qwerty to Dvorak in my 20s, and now from Vim to Helix in my 30s. Both transitions were rough for a couple of weeks, but honestly less difficult than expected. Neither choice turned me into a 10x developer, but neither one has ever caused a problem that I cared about either. Do you spend a lot of time on systems that you don't control? Dvorak discourages other people from helping themselves to my keybo…

> being able to go the opposite direction

I bet you could learn to "switch" if you really cared to. Reminds me of the reverse-steering bicycle video from SmarterEveryDay. https://www.youtube.com/watch?v=MFzDaBzBlL0

Re: From VS Code to Helix

#140

Post by BowBun »

miroljub wrote: post #63
BowBun wrote: post #33

Earlier quoted context omitted.

> I'm sure I could learn to be slightly faster on dvorak/colemak, but nothing beats the convenience of always having guaranteed access to qwerty, everywhere I go. Citation needed. Of my 2 friends that have tried, neither have been able to reach their 'standard' typing speed after 1+ years of dvorak. Maybe they didn't try hard enough?

> Citation needed. No, not needed. This is not an HN comment posting a subjective opinion, not a scientific work that requires real, or a Wikipedia article that requires any citation.

It's not an HN comment, not a scientific work, not a Wikipedia article. So what is it?

Sorry, had to match your level of pedantery.

Post reply on HN