Build muscle memory with your favorite editor | Hacker News Reader

Build muscle memory with your favorite editor

shortcutfoo.com

443 pointsswalberg119 comments

This really didn't work for me. I found needing to parse the command ("Move backward a word") broke the memory that I have built up over 15 years of using Emacs. Instead of naturally moving backwards with a flick of the fingers, I had to concentrate on where each finger was and on the key I was pressing.

I think the goal of this is great, but as it stands, I'm not convinced it is going to help. Given it aborted my natural wiring, I doubt it will be wiring things up correctly for people who don't have the wiring (I could be VERY wrong here!).

Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.

It could show a typo where it wants you to move, like:

Hood news, everyone!_ [Ctrl-A]

I agree. When I use vim, I just know the key to press to move around. I don't think "move to the next word -> w". I know I want to move the cursor and my fingers know where to be but not really what key I am pressing.

Sounds like you are already there then. This gets you back into the cognition of it all which you aren't used to because you don't have to think about it. Its probably more helpful for people with less experience. I too find myself getting confused when reading about VIM because I don't think about it that much.

Just to contrast, as somebody that's a novice-to-intermediate vim user, I really like this so far. The action verb model feels like it mirrors how I think when using vim, so at first blush, for me at least, it feels like a good fit.

I don't know enough about Emacs to compare there, though.

It may be that muscle memory in editors is created like this:

  1. Identify a problem
  2. Think what I need to do to fix it
  3. Decide what keys I need to press
  4. Direct fingers to press keys

And that gets shortened eventually to:

  1. Identify a problem
  2. Direct fingers to press keys

If that is the case, then this might be a really good first step towards that process. I would certainly not look to me for that initial feedback.

Perhaps if I could try more complex things (that I don't have current muscle memory for), I would find it incredibly useful.

Either way, getting better at using your tools is always a good thing.

That's actually a very good description of my experience learning vim so far.

It starts off being a very conscious set of actions when first learning a new command -- e.g., "I want to change the word under the cursor... cw" -- before becoming something that happens subconsciously as I become more familiar with a set of commands.

Where this site at least appears to work well is that once I started to understand vim commands as verbs and nouns, I started seeing actions as sentences. The drills here seem to reinforce that sentence structure type approach.

I can see it being less useful for somebody that is familiar enough with their editor thatt it's already become a mostly subconscious process. While I'm comfortable using vim for the most part, I'm very far from a high level of proficiency with it.

> Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.

Yes, they really need to take the words out of the equation. It's just a superfluous modality that gets in between the muscle memory, the goals and the training.

Of course, this method will get you familiar with shortcuts rather quickly (I only tried the Vim ones), but then, so does printing out a cheat sheet, or reading some tutorial and an afternoon of practice. While I do believe ShortcutFoo does manage to teach that more effectively than those methods, that's not where it could really shine.

To become a pro text-editor user, you really need to go beyond that, hence muscle memory, not just "memory". You don't merely need to remember the shortcut for "go one word back" when presented with the written goal "go one word back", no you must intuitively know the shortcut as soon as you identify the goal already on an abstract level.

Even with a simple default editing control like this text box: As I'm typing these words, I'm not thinking of every letter I type, I don't think about whether I need to "move cursor left five times" or "move cursor left one word" or "delete word to the left" etc, I'm thinking about the sentences and ideas I want to put into this post and operate the keyboard to make that happen--and any literal textual description of shortcuts and movement commands would really just get in the way with my thought process.

I haven't seen @gruseom's post yet, so maybe s/he had the same idea but: Something like a phantom cursor that indicates "get the cursor to here" or half-fade a word that you must delete? But that may become too low level once you get more advanced. What you really need is a sort of visual indication that shows a diff between the original text and the goal text, you get to look at it to take it in while a quick countdown timer goes 3-2-1 and from that point it times how quickly you can edit to the target and how many keystrokes it takes you to do it. (could even make it a colour-coded actual diff, then people get to train reading diffs as well :) [something I need to practice myself])

Further,

I don't want to need muscle memory for editing!

I would take the hard stand that any repetitive keystroke combinations inherently implies inefficiency - ie, an ideal editor should provide enough shortcuts to give your keystroke stream a fairly high entropy content. Maybe we're not there yet but I don't want to develop habits which would stand in the way of such an ideal.

But that's what the muscle memory is for. If you only ever used the arrow keys to move around and backspace to delete one character at a time, you won't need any special tool for memorizing which key to use!

The whole reason this tool exists is because the best text editors (Emacs ;)) do have a ton of different commands. So now you have to learn that when you wand to delete a word in front you use M-d.

The "muscle memory" is just associating each of the many discrete keystrokes with an action. So instead of thinking "hmm, I need to delete this word, I'll press M-d" your hands just go to M-d as soon as you realize the word needs to be deleted.

This is exactly the sort of memory you need to deal with a high-entropy command stream quickly. The ideal would be to use a ton of different commands without thinking about them at all.

Now, I don't think this site is ideal for this sort of learning, but it's a step in the right direction.

>This really didn't work for me. I found needing to parse the command ("Move backward a word") broke the memory that I have built up over 15 years of using Emacs. Instead of naturally moving backwards with a flick of the fingers, I had to concentrate on where each finger was and on the key I was pressing. ...

>Now, take @gruseom's idea of a visual "goal" that you are chasing, and I think this could be intensely valuable.

I made exactly your suggestion to the author a while back, since this site was posted on HN about a month ago. A few days after that, I went to a TrueCar Ruby meetup where the author presented his shortcutfoo app, and when he asked for input, I made exactly your suggestion:

Since, I reasoned, you never go from "verbal description of alteration" to "keyboard input" in actual practice, I said that it would make more sense to give some visual representation of what the desired change looks like, since that is a lot closer to how people use these shortcuts (although not an exact match, of course). Someone else then followed up by suggesting that it display "before and after" pictures (what the text/cursor look like before and after the modification), which would be pretty easy to implement.

I don't know why he didn't take that suggestion, but it's unfortunate that he hasn't.

Earlier post: http://news.ycombinator.com/item?id=4007096

I agree - just did this for vim. I don't think "move to end of whatever" I know what outcome I want. I never "say" it in my head.

To elaborate a little, I'd like to see a "you are here":

http://i.imgur.com/fDYEJ.png

you want to be here:

http://i.imgur.com/ijn0g.png

type thing. Not sure if this would work for other editors.

This is neat, but one thing it misses is the "reward." Not a gamification award, but the visual feedback from hitting a keyboard shortcut and seeing it actually happen, which helps reinforce the connection from muscle-action to program-action.

Another important component is seeing the scenario. Seeing the words "Duplicate line" doesn't hit the same neurons as seeing the situation in the text-editor that toggles my brain to think, "I need to duplicate a line here".

Obviously, none of these features are trivial to implement. Great work, though!

If it had "seeing the scenario", I would've immediately bought it and would have been willing to pay at least $15.

I agree that the visual correlation to the shortcuts is important. It's a very nicely designed and implemented idea, but I think I would need that visual component to warrant paying for it (the visual component would also justify a higher price for me as well.)

False. Why gamify, I actually found this incredibly useful all in itself.

You misunderstood me. I said a reward, but not gamification. The reward when you complete a successful duplicate line shortcut is that you see a duplicate line. This helps associate result with muscle action. I'm arguing that this cements the memory even more.

This is neat and promising. I agree with other commenters that the weakness is in telling the user what to do in the form of text like "Move cursor to beginning of line". Routing the muscle signals through text processing in the brain is slow and isn't what goes on when you actually use an editor. i.e., there's no text in a marquee in one's head telling one what one needs to do next. Since keyboard shortcuts are all about habit and speed, you definitely don't want to require any atypical or slow mental processes.

For cursor movement you could show a buffer of text with some kind of target thingy that moves around, and you have to chase it using keyboard commands. That might be fun. It would also be simple to create an efficiency score based on how many commands the user used to get where they wanted to go.

For text manipulation you could provide some auxiliary visual indicator of what needs doing. For example, to practice deletion, have a buffer of text and some visual indicator of a character, word, or line that needs deleting. Say it flashes (probably a bad choice, but whatever). Then the user's job is to use the right shortcut to delete the flashing thing. At first, the software could move the cursor to the right place before each new command. For more advanced users, you could tell them "First move the cursor to the right place and then invoke the right command to delete the flashing thing". As soon as they delete one bit, another bit starts flashing. You could measure how long it takes to delete everything in the buffer this way. That might be fun too.

See http://vimgolf.com/

One for Emacs would be fun

That looks fun, but also intimidating. It makes me think that maybe tracking efficiency is a bad idea for learning after all. To stop and think about whether one's doing X in the most efficient way stymies flow.

Come to think of it, in Emacs I often do things inefficiently – in the sense of using many more commands than the technical minimum to do a task – because the basic commands are already "compiled" in my head. If I have to stop and grope for a less familiar command that could do the job more directly, that's like switching to interpreter mode, which is much slower. So in the short run, it can be more efficient in time to be less efficient with commands. This is the chicken-and-egg problem where one doesn't invest the effort to acquire new tricks because one's too busy doing one's job with the tricks one already knows.

The goal is to get more tricks into the compiled set (muscle memory) more easily. I suspect this is a "don't make me think" kind of challenge. One has a limited budget of thinking energy and typically needs to spend it on more important things, so one doesn't have anything left to invest in getting better at Emacs or whatever, even though one knows one "should". The challenge is how to move this kind of knowledge into muscle memory using some cheaper pool of energy.

This is probably a solvable problem because the commands we're talking about are so mechanical. They don't need to go through the most expensive cognitive process; our goal is to forget them on that level anyway. But I haven't seen any teaching tool with a low enough cost in this sense. The OP comes the closest, which is already impressive. And if you can learn editor commands this way, there probably are a lot of other useful things you can learn this way.

It would be, which is why Tim Visher has been doing VimGolf in Emacs for a while. :)

http://vimeo.com/channels/222837

have you seen vim-adventures.com ? it's only for vim, but it might be what you are looking for

I took a look and yes, I didn't have to think much about what to do, and nearly all my effort was spent actually toying with h-j-k-l. I don't know vim at all so I'm good for a newbie test there.

Edit: I just realized what bothered me, though: it doesn't look anything like vim. So there's a context loss, which feels like it might degrade the value of the learning.

I wonder if this actually teaches you the right kind of muscle memory.

I have no difficulty with hjkl for navigating in Vim, but I had trouble associating those keys with the string "move <up/down/left/right> one character".

Mapping from the description of the command to the key is not the kind of muscle memory I use all day.

even though the project looks good, this is spot on.

Agreed, this is the strangest way to learn an editor. The whole point of pressing a command is to see what it actually does. Connecting that action to your muscle movements is what you want.

Agreed. Perhaps a block of text/code with lines highlighted along with instructions on how/what to change them? That would give the right visual feedback and should be totally doable.

Yeah, it would be awesome to see prompts like:

> Duplicate this line

> Move the cursor to the beginning of this line|

Agreed. Same problem here. Perhaps a visual display of what needs to be done would be a lot more useful. I have no clue of how this could be done though. At the same time if you want to build muscle memory, just use the damn editor and you get it eventually :)

One thing I learned from this is that I don't know my directions. I was consistently hitting h for right and l for left.

Wow. Nothing like waking up on Monday morning to find your app at the top of Hacker News. Thanks to whoever posted this :)

This is awesome feedback. It looks like the most requested feature right now is moving from reading words to a more visual representation of what's happening. This is definitely something I've thought about - but didn't want to attempt until I received exactly this type of response. Thanks! I'll definitely move this up as a top priority and hopefully have something implemented soon.

Thanks for everyone else's feedback. I'll carefully read each post and email I've received and respond appropriately.

Someone asked about the tech stack: backbone.js + sinatra + mongodb hosted on heroku (2 dynos). I'll try and get a blog post up with more on this plus possibly a HN postmortem if there is interest.

ps. I'll get eclipse added as well :)

Can you send an email when/if you implement that? I think there are lots of people that would be more willing to buy it if you have that.

You can also enter command mode in Vim with ^[.

I spent a few minutes trying to figure out how to give you this feedback before I saw your comment here. Maybe you should list an email address or have a contact form somewhere on the site. The only thing I found was a Twitter account, and I'm not on Twitter.

If you want better shortcut muscle memory, just unplug your mouse for a couple days. Do this once a year or so. You can thank me later.

In OSX, are all dialogue boxes able to be accessed by the keyboard?

Not sure about OSX, but in Windows you can. This is a huge miss in Linux I find (all distributions I've tried so far), you need the mouse to get anything done without resorting to a terminal.

Yes, but you have to enable it. It's not on by default.

System Preferences -> Keyboard -> Keyboard Shortcuts

And change the radio at the bottom to "All controls" under Full Keyboard Access.

To get to System Preferences, you can use CTRL-F2 to get to the Apple menu, CTRL-F3 to get to the Dock, or—if those shortcuts aren't set up (but I think that they are by default)—CMD-TAB to get to Finder, CMD-A to get to the Applications folder, and type a few letters to get to 'System Preferences.app'. :-)

In the System Preferences window, you can start typing to select 'Keyboard' (keyboard focus is in the Spotlight menulet).

You can tab to the 'Keyboard' / 'Keyboard Shortcuts' tab bar, then arrow over to 'Keyboard Shortcuts', then tab to the 'Full Keyboard Access' radio buttons. Sadly, these last few steps require that Full Keyboard Access already be turned on! The text below the radio buttons says that you can toggle the setting with CTRL-F7, but that doesn't work for me; I'm not sure if some other keybinding is interfering.

Event quicker ⌘+space spotlight and type `keyboard` =)

Do you have the 'use F1, etc as function keys' unchecked? You'll need to use fn+control+F7 instead.

Nope—the machine is a laptop, but I'm using an external keyboard. For example, CTRL-F2 and CTRL-F3 both work fine.

How do you keyboard navigate the TextEdit save dialog that comes up when you Cmd+w on a window when you don't want to save it? (Can you do better than press tab 5 times then space?)

Prior to Lion, Cmd+D means "don't save" in the dialog. With Lion, it's Cmd+Backspace.

Working once on a MacBook with a disabled trackpad, I found the only window that I could not focus using the keyboard was the password dialog. I realized later that AppleScript could do the trick:

    (as root)
    # ps axo ucomm | grep -q SecurityAgent && osascript -e 'tell application "SecurityAgent" to activate'

I believe they are if you enable 'Full Keyboard Access' for 'All Controls' in the Keyboard prefpane (under Keyboard Shortcuts tab)

Or just hit Control-F7.

There's a direct way to do this:

Command + first letter button title

will activate that option, with a few caveats - Command-C won't work as Cancel, but Command-. will.

Step 2: undefine the arrow keys.

In vim you can do that by putting these lines into ~/.vimrc:

  map <up> <nop>
  map <down> <nop>
  map <left> <nop>
  map <right> <nop>
  imap <up> <nop>
  imap <down> <nop>
  imap <left> <nop>
  imap <right> <nop>

This will disable the arrow keys in normal and insert mode.

I'm not trying to be difficult here, just genuinely curious: why disable the arrow keys? Is it simply the speed boost you get from using hjkl on the home row vs moving your hand to the arrows?

I use Colemak, so hjkl is very counter-intuitive for me, whereas the arrow keys make sense and aren't /that/ far away.

EDIT: http://news.ycombinator.com/item?id=3684515 has some good explanations. So does anyone have suggestions for non-QWERTY users? remap the keys that are in the HJKL space, leading to a cascade of keys moved around? Deal with the counter-intuitiveness of actually using HJKL?

Dvorak users can get away with using hjkl with the dvorak layout - it's not that counter-intuitive. Your Colemak layout, however, looks beyond salvageable in terms of using Colemak hjkl. I think a re-binding is in order there.

When I use Vim I barely even use hkjl except to fine-tune larger movement commands. I'll search for a symbol, or move word-by-word, or use f/F/t/T to move to a different character on a line, which gets me in the ballpark.

Even if hjkl is faster, I would be optimising for a case that just doesn't show up that much.

Or, remap the hjkl of vim, a ridiculous legacy of an obsolete keyboard Bill Joy just happened to be using at the time, to the normal inverted-T of cursor movement: ijkl. Then continue using the "arrowkeys" that are now under your right hand on the home row.

You'll then need to move the insert on left side of cursor, which was i, to h, the key on the left side of your index finger. Reach left to insert left. Easy for muscle memory. With that, both sets of arrowkeys on the keyboard work the same, and you won't need to disable one of them. Normal arrowkey muscle memory, and reach left to insert left. So easy.

Bill Joy was working in an era when keyboards didn't have separate arrowkeys and the ESC key was within easy reach. He wanted it to be as easy as possible to remember lots of different command keys. He used what was printed on his key caps, such as a straight line of arrows on hjkl and various English words such as "yank" in his design. It was a good idea at the time. He also realized that keyboards varied, so he made it all remappable to adapt to future keyboard designs--also a good idea.

But the programmers themselves couldn't adapt. The choices Joy made for that obsolete keyboard were frozen in amber by programmers whose habits were frozen in amber. These days, almost all keyboards have real arrowkeys, and people develop the muscle memory to use them long before they ever hear of vim. Also the ESC key, such a fundamental key, is off in Siberia.

For every vim user with vim habits based on an obsolete keyboard they don't use, there are 10,000 potential vim users with keyboarding habits based on the modern keyboards they DO use. Those 10,000 people use inverted-T arrowkeys, x/c/v as cut, copy, paste, they can't reach their ESC key, etc. Vim was designed to adapt, but old vimmers apparently weren't, so the design features that give vim its power are forever stuck behind arbitrary key layouts optimized for the wrong keyboard.

It makes more sense to remain consistent with existing muscle memory and keyboards, using the inverted-T arrangement ijkl, mapping your left-side insert to the left side key ('h'), and mapping ESC to something easy to reach, such as ';;'. Then, if you ever need to use a non-customized vim, just use the real arrowkeys, which will still feel natural. If you ever need to use another app with a serious vi mode, like zsh, it will be remappable to match your vi. (If it's not a serious vi mode but just a couple of vi-like keyboard shortcuts, either use the arrowkeys or do what we always do, given that every app has its own unique set of keyboard shortcuts: just learn a few new shortcuts for that app.)

What's so ridiculous about hjkl? I'm actually an emacs user, and I've gone to great lengths to set up hjkl layouts in my editor and browser.

It seems like the perfect setup to me. An inverted T would cause you to reposition a finger every time you wanted to change direction. I do that often enough that it doesn't seem very efficient to me. I had some doubts as to whether jkl; would be a better option, but it really does seem more convenient to have the "down" key below your index finger.

This is similar to how I learned the DVORAK layout actually. I switched to DVORAK, made sure that I had a couple of essays pushed off til the last minute, and bam! I knew it like the back of my hand by 3AM.

Dvorak was a long process for me. It took me about 3 months to get to 70 wpm (was 120 qwerty). Online gaming had a lot to do with the delay: switching keybindings for every game was annoying, and I needed to quickly communicate with teammates (or smacktalk opponents ;P)

No need to be so drastic! - just put it on the other side of your desk.

I've done this a few times when I've needed the space for taking notes. I'm now pretty good at mousing with either hand - but the key part is not making mousing more annoying, like it was the first time I swapped, but rather just making you realise when you're reaching for it. That gives you a chance to consciously think about what you're about to do. And then you have a chance to decide that you're going to figure out how to do it with the keyboard.

I'm hoping to get there soon. On linux, I use vim, a keyboard centric window manager and I've recently started using uzbl for my web browsing. Not there yet, but getting there - already I find I don't need to reach for the mouse very often at all!

If you get something wrong, and what you type is longer than the expected answer, you end up failing the next couple of questions too.

muscle memory - if you type eg "uptime" when the answer should be "free", it fails on the first character, but you're still typing, by which time it's on to the next question. which you then fail, because the answer to the next question isn't "ptime"

Yeah I noticed this when I opened it and tried to cmd+t a new tab open at the same time.

Yeah, this is a problem. Also, having some nice visual feedback when I get one right or wrong would be great.

That said, this is an awesome service and I'm going to pay for the premium account just to support the effort. I'm in the process of switching from a tricked-out gedit along with nano to just using vim, so this is a wonderful resource. I'd highly recommend it to anyone trying to learn vim. In the course of just 10 minutes, I've already learned another 10 commands. Assuming I practice them another day or two, they'll become permanently part of my vim repertoire.

EDIT: To clarify what exactly I'm using this service to do: I'm using it to eliminate the constant need to refer to a vim reference card. The muscle memory will come only from using these commands in vim, but being able to eliminate the need to constantly refer to a vim reference for new commands is a huge plus. I've already learned 10+ new commands that I no longer have to look up. PS - paid for the premium.

Textmate: ⌘-[ for shifting left is "History > Back" in Safari and happens every time when it's the last shortcut in drill mode, which happened to me both times I tried.

Otherwise nice tool. I agree with the others about visual feedback. For Photoshop: Show the part of the palette you want instead of the name of the tool.

No Eclipse? :(

There goes a large chunk of users. You'd think this would be one of the first editors to have made the short list.

I'm a little surprised at the lack of Eclipse support, given Java is one of the most popular languages and Eclipse is the most popular Java IDE

http://zeroturnaround.com/wp-content/uploads/2010/11/IDEs.pn...

I like it however I am stuck on "Open last closed tab" for Sublime in chrome. Whenever I type it chrome opens the last closed tab....

Another issue for Emacs, C-n in Chrome opens up a new window.

Try tapping ABACABB (the Mortal Combat blood code) on the homepage for some fun. Nice easter egg :)

I feel I must ask: do you try this on every website you come across, or do you check the source on every website you come across? Either way: thanks :D

This was on reddit a couple of days ago: http://www.reddit.com/r/programming/comments/wjyvw/shortcutf...

I actually work with Watson, the creator :) So I cheated a little.

Had this idea too, glad someone has executed on it so awesomely. I've been eager to get better at Sublime Text, so will start using this.

Two suggestions which I think would be really awesome.

!. The hard part of exercising though is getting your butt to the gym. What if you could sign up for a daily email that keeps you at it, challenging you to take it to the next level, tracks your progress, sets goals and reminds you to make them, etc.

2. It's really abstract to just hit key commands without seeing them actually do something. What if you made small animated gifs for each action your are emulating, maybe even with a full fake editor background? This way, your brain would be tricked further that you are actually performing the action represented by the keyboard shortcut.

Cool site, but a minor annoyance, is that some editors, like vim, have multiple ways of accomplishing a task. For instance move to line 4 can be done with 4G or 4gg, but only accepts 4G, which is frustrating as I've already internalized 4gg :) I'm sure there are others.

Add :4<CR> to the list of possibilities.

That's really fun. I love the site design, very slick.

Found a "bug". Some of the keyboard shortcuts conflict with my browser shortcuts.

For example, in one of the emacs drills, to move down a line (ctrl + n) it causes chrome to open a new window... so I could never complete the drill because of this.

Am I the only one that can't get this to work? First the legend shows a few of the keys as ⌥.

Then, say for Sublime to cut a line it's ctrl+shift+k. It shows K.

So I try hitting ctrl then shift - nothing. I try typing ctrl then shift - wrong. I try entering a caret (^) for ctrl - wrong.

Just what are you supposed to do?

Wow, this is actually fairly awesome. Works better than the vim cheatsheet I have hanging next to my monitor.

That said, the site can be pretty confusing. What's the difference between practice and drill (other than slight interface difference?)

Seems like the drills count towards your accuracy scores, while practice does not.

It would be nice if the prompts at the end of sections could be easily keyboard-activated. (For instance, the "Start Drill" button that I have to take my hands off the keyboard to click.)

This is great, I've seen a web game that you can use to practice vim schortcuts. But since this one's about building muscle memory, I don't see how this is going to be better than the actual use of the editor itself. Using the actual editor not only gives you the actual feeling but also challenge you with the real text editing tasks. CMIIW. But this is still useful if you just want to see a cheatsheet or not knowing certain shortcuts in the editor.

I think the point is that when starting out with a new text editor you aren't moving fast enough to use these shortcuts that often, so it's harder to internalize them. With this you just get rapid repetition, so that when it comes time to use them you have the command at the ready in your head. Of course I'm speaking from the point of view of someone just starting out using an editor. For someone that has already used any of these editors for any length of time this sit does seem kind of worthless.

This is great, similar to the code drills posted a couple of days ago, pretty good way to get that crucial memory in place. Did drill, would drill again.

I have to enable way too much stuff in NoScript to proceed when I actually click on an editor button. Giving permissions just to shortcutfoo is not enough. NoScript also shows airbrake.io, stripe.com, olark.com. I don't know what any of those are, so I'm not enabling them. So I cannot use your website, as cool as the premise sounds :/

Your loss, because it's awesome.

In order:

1) exception tracking api 2) payment processing api 3) live, on-page chat tool

noscript is cool and all, but those 3 above listed items are perfectly fine to permanently enable on all sites

I would argue that #3 would be one I'd like to have blocked. I've never had a situation where those "Hey! Wanna chat with a salesperson!?" boxes isn't annoying.

I only use vim, and from using this site for 3 minutes there's clearly plenty of knowledge that I'm missing. I really wish that it would teach me the commands it was drilling me on, and not just expect me to know the key strokes. I know I can pull up the shortcuts reference, but I feel like it should train and hint, then drill.

Some keys are confusing to read under the pulsing cursor. | overlaps b, k, h. e.g., h look like n.

Add a shortcut key for Start Drill!

I feel like this is the equivalent of obsessing too much about going to the gym. What about good old "on the job training"? The shortcuts you need, you will eventually internalize... instead of using up time on an exercise like this. I mean, it might give some benefit, but is it worth the mindlessness?

What I found missing in this is _why_ I would want to jump to a matching bracket, or insert a line before.

Perhaps the game should be to transform one block of code into something different in as few keystrokes as possible.

I would love to see videos of people using commands that are not a part of my current vocabulary.

> Perhaps the game should be to transform one block of code into something different in as few keystrokes as possible.

Related, http://vimgolf.com/ but vim-specific..

Neat.. kinda fun.

One thing is you might want to allow people to configure the META key. I have Emacs set up so that the Command key is META, so all my muscle memory is ruined when trying to run through the drills.

But I like the concept and might use it to increase my shortcut kung-fu.

Command key now works as META for Emacs. Thanks for the suggestion!

I think a cross between this and vimgolf would be really good. Basically where you just get things you need to do like changing the paragraph formatting and you just implement them to help you get in a state of flow with your editor.

A great idea.

Ctrl-shift-T is the key for repeating duplication in Photoshop, but it's also the shortcut for create the most recent tab in Chrome, so it's impossible to enter it unless you change your browser settings, which I'm not sure I want to do.

I thought this was a great idea. But I simply am an idiot and can't figure out how to use it. They tell you to type these || characters and it always spits back a fail when I try it. They need more user testing feedback.

Love the concept, however this is much like learning a language by learning to translate.

求 -> ball -> O (actual ball)

求 -> O (actual ball)

Classic study vs immersion.

The implementation will be much harder, but for this to be effective show the manipulation, not the description.

It's nice, but I'm not sure that's how my mind works when I'm working in VIM. I wonder how I'd react if I was put in an actual document and then prompted somehow to do the same exercises.

This is a fun project. But I'm not sure about the 5 bucks. Seems like it's begging to be rich too soon. This app is just revealing information you already have on a cheat-sheet.

I found it confusing because it was using capital letters when shift wasn't implied. So I'd hit shift to capitalize like it displayed and it'd be wrong.

Hmm, I seem to be having a font-related problem, both CTRL and ALT symbols show up as (empty) squares. I'm running Chrome 22.0.1201.0 dev-m on Win7.

I really liked this. Unfortunately emacs bindings are the same as browser bindings so I kept killing my browser session and or browser tab.

Can it be easily extended to add new editors? Perhaps you can let the users submit packages for their favourite editors...

This looks cool. Maybe you can consider a similar format to learn languages (e.g. memorize words or grammar rules?)

Nice. Is there more info about how you wrote it? Which platform is this running on? Which tools you're using etc?

Neat. But I have Emacs configured to use the command key as Meta, so this needs to be configurable in the drills.

I've also used too many terminals that didn't pass through Meta that I often use Escape instead. That didn't work.

That's great, but you should accept all valid shortcuts. Move to beginning of line in XCode is ^A as well as ⌘←

Seems rather pointless. If a command is useful, you'll get muscle memory from actually using it.

My pinky hurts after using this for sublime for a few minutes, and I'm getting emacs flashbacks!

Anyone else experience out-of-whack CPU usage when loading up a tutorial?

In the absence of textual context its hard to find these drills helpful

Awesome! Been subconsciously looking for something like this for ages..

Well executed. `dw` is not "delete word", though.

My vim doesn't get the ^ keypress :(

Brilliant piece of work - nice one!

No BBEdit. sigh

Wow, this is great!

Not only is this a beautiful and helpful web app, but it supports many different editors instead of taking part in the text editor wars.

No support for Eclipse or IntelliJ IDEA or, heck, Netbeans, though.

It's also missing the Brief keyboard mapping :(

Reply on news.ycombinator.com