Live data from Hacker News

Build Muscle Memory With Your Favorite Editor

shortcutfoo.com

1–10 of 18 posts

Re: Build Muscle Memory With Your Favorite Editor

#3
neat, but for things like the editors it'd help to see the action happen along with a description.

example ctrl-f in emacs. along with the description "move forward a word" i'd also like to see (perhaps on the side of the screen) an editor move a word ahead. That way there are two reinforcements; the verbal description and the observed action

also many of the shortcuts trigger browser shortcuts. I don't know a workaround, but it's mighty irritating.

Re: Build Muscle Memory With Your Favorite Editor

#4
Interesting, but for me useless. I use vim each and every day, and I think I have a good claim to some muscle memory. But this excercise asks you to press keys with no context. I can navigate with hjkl just fine, but actually struggled to remember which key to press. But in vim I'm fine. Separating the shortcuts from the editor is not a good thing.

Re: Build Muscle Memory With Your Favorite Editor

#6

Interesting, but for me useless. I use vim each and every day, and I think I have a good claim to some muscle memory. But this excercise asks you to press keys with no context. I can navigate with hjkl just fine, but actually struggled to remember which key to press. But in vim I'm fine. Separating the shortcuts from the editor is not a good thing.

Exactly, that is what muscle memory is about --- it's an unconscious thing. I find the same is true for typing too - if I actually try to think about where the keys are, I slow down dramatically - and I have absolutely no problem typing at full speed a word I've never seen before, although I don't know what keys I pressed or how to spell it after I did it.

Re: Build Muscle Memory With Your Favorite Editor

#10
While I'd definitely advocate getting extremely comfortable with your preferred text editor, this does not seem like a good approach at all. These drills ask you to do a specific command by description ("Move one character right"), which creates an association between that description and the editor action. However, when you're working quickly in an editor, you're thinking at a much higher level than "move one character right"; you're thinking about how to perform some higher-level action involving code navigation or editing.

It would make more sense to present an editor and ask the user to make a specific high-level change (such as refactoring a function), let the user do so, and then analyze their input to figure out whether they could have done so more efficiently. For instance, in vim, did they navigate by hitting hjkl or use a more efficient /search, and did they hit delete/x repeatedly or use something like c2w?

Post reply on HN