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.<p>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?
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.
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.<p>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).
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.
neat, but for things like the editors it'd help to see the action happen along with a description.<p>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<p>also many of the shortcuts trigger browser shortcuts. I don't know a workaround, but it's mighty irritating.
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.