this post was submitted on 09 Feb 2025
108 points (99.1% liked)

Programming

18143 readers
177 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

When I was in high school I found Sublime Text and learned "multiple cursors". Since then, I've transitioned to vscode, mainly because I need LSP (without too much configuration work) for my work.

I keep hearing about how modal editing is faster and I would like to switch to a more performant editor. I've been looking at helix, as the 4th generation of the vi line of editors. Is anyone using it? Is it any good for the main code editor?

The problem that I have is that learning new editing keybindings would probably take me a month of time, before I get to the same amount of productivity (if I ever get here at all). So I'm looking for advice of people who have already done that before.

My code editing does involve a lot of "ctrl-arrow" to move around words, "ctrl-shift-arrow" to select words, "home/end" to move to beginning/end of the line, "ctrl-d" for "new cursor at next occurrence", "shift-alt-down" for "new cursor in the line below", "ctrl-shift-f" for "format file" and a few more to move around using LSP-provided "declaration"/"usages".

I would have to unlearn all of that.

Also, I do use "ctrl-arrow" to edit this post. Have you changed keybindings in firefox too?

you are viewing a single comment's thread
view the rest of the comments
[–] jeffhykin@lemm.ee 5 points 1 day ago* (last edited 1 day ago)

Input speed is not "just" input speed.

Note: I'm not about to argue for or against modal editors, I just want to answer: why is input speed really really really important, when (we agree) its not a big percent of total time.

5min at 80mph over a bumpy dirt path is very very different than 5min of flat smooth straight driving. And not just because of effort.

A senior and junior dev could spend the same amount of time to rename a var across 15 files, move a function to a new file, comment out two blocks, comment one back in, etc. But. When I try to have a conversation while they do that, or when I change my mind and tell the junior to undo all that, its a massive emotional drain on the junior.

But effort isn't the whole picture either: speed is a big deal because pausing a conversation/mental thought for 5 seconds while you wait to finish some typing, is incredibly disruptive/jarring to the thought-process itself. That's how edge cases get forgotten, and business logic gets missed.

Slower input is not merely input time loss, it also creates time loss in the debugging/conceptualizing stages, and increases overall energy consumption.

If the input is already fast enough that there's no "pauses in the conversation" then I'd agree, there's not much benefit in increasing input speed further. BUT there's almost always some task, like converting all local vars (but not imported methods) in a project to camel case, that are big enough to choke the conversation, even for a senior dev. So there's not necessarily a "good enough" point because it's more like decreasing how often the conversation gets interrupted.