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?

Immediately after trying it briefly I had the same thought. I wonder though if you could ever really describe what the "best" way to do something is in Vim. I believe we could be pretty clear that "xxxxx" is less efficient than "5x" or "daw", but in different contexts different ones would be appropriate.

If the goal is just muscle memory for beginners, I think instead you might want to have specific actions at a high level with the goal of using particular families of commands. For example, swap the highlighted two words in the following paragraph using only full-word commands. Then it could have a very clear and expected input for you to use as a goal and you could practice doing it.

You can't uniquely identify one method as "best". In particular, there's a limit to how much you want to learn and use specialized commands versus a core set of broadly applicable commands. However, you can identify a set of broadly applicable commands that proficient users should know, and make sure they're at least using those, if not something even more specialized.

For instance, suppose you're sitting in the middle of a line, and you want to add a word five words to the right on the next line down. j5wi or /sometext[enter]i are both sensible ways to navigate. )wi might make sense if the insertion point is just after the end of a sentence. jwwwwwi is not horrific (given that visual counting may not be as fast) but probably deserves a warning as a reminder. jllllllllllllllllllllllllli is well worth warning about.

What about showing the cursor in the middle of some placeholder text, and highlighting the desired final cursor position with a red dot? This would offer a very specific goal to the user without the need for more complex, high level actions.

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.

I'm a proficient VIM user of approximately five years, and I was utterly useless on this training program.

I don't think that training on it would be useful at all.

The drill told me I was wrong to press ctrl y for redo instead of ctrl shift z. I loaded up visual studio just to make sure I was right. (I was)

Tried the Excel ones - seems to work well enough. Except the shortcuts are not the ones I use daily...and Excel has a lot of shortcuts so matching the drills with users might be a hint tricky.

I think what's more important is the meta-level skill of noticing when what you're doing should have a shortcut, and then finding or making a shortcut for it.

For textmate, I'd recommend learning just control-command T and the program-level shortcuts (closing many windows, opening the "go to file" dialog box, making a new file, etc).

Vim users may find this more useful: http://vimgolf.com/

Emacs, unsurprisingly, has a native key quiz program which is similar though more random. The package is called `keywiz`. I play it when waiting for stuff to compile and have picked up a trick or two.

Won't this be useless if you've changed any of the shortcuts?

Things seems a little buggy. It just told me that alt+b was wrong for backward word in emacs, but that's what it just told me was how to do it in the learning portion of it.

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.

This is awesome OP, have been waiting for something like this.

really helped me increase my coding speed by honing my resharper shortcut skills