Just now I was able to select the previous sentence with about 3 keypresses. Copy and paste would be a standard ctrl-c/ctrl-v. No worrying about mode, or counting characters
j-V-p = 4 which is a lot less than 3+2+2 of what you described. So your point about vim requiring more keypresses seems moot.
First, I was inserting, so it would be ESC-up-V-something, and ESC requires my hand to leave the wrist rest. Problem is, I occasionally don't notice I'm inserting (or not), and as you pointed out above, that means that half my buffer is now screwed up and I have to shift mental gears to fix the damage. That alone is unforgivable.
Second, I hit Shift-Up-Ctrl-Left-(Release Shift)-C. I wasn't selecting the LINE, I was selecting the sentence, which ended in the middle of the line. And the keys are all grouped usefully AND ergonomically. Between the arrows, shift, control, home, and end, I can select characters, words, lines, here to the start of line (or buffer), here to the end of line (or buffer), and throw in insert and delete and I can copy, cut, and paste, as well. All using keys that are standard to almost every app on Windows (and Linux, for that matter). When it's that easy, why would I also feel the need to train for a completely different set of key strokes?
I was giving as an example how MOST of my finger key memory works even when in Chrome, and the same is true of almost any Windows application I'm in. I don't need two vastly different sets of keyboard skills depending on whether I'm programming or writing on HN.
When I AM in SlickEdit, I can hit 'up' 'ctrl-c' to copy the previous line (copy is set up to copy the current line when no text is selected). If I want to select lines like you did in vi, I can hit ctrl-l. A square block, ctrl-b. The current code block, shift-ctrl-]. Everything nice and mnemonic, and automatically "visual". But most importantly, no modes to remember, manage, or otherwise distract me from coding.
You can argue all day that one key press plus or minus doesn't make much difference. But some key combinations are well designed from a user interface perspective, and some less so -- and regardless of the merits of the design, using the one that works everywhere that ISN'T vi means you're that productive everywhere.
Where vim/gvim really falls short for me (beyond anti-ergonomic key bindings) is that I really want it to be an IDE, not just an editor. I can ask SlickEdit to open a file by typing a few characters of its name and then selecting it from a list of all files in the project that match. I can tell it to build and end up with a list of errors that I can jump to. I can ask for symbol cross-references throughout a project and it will find them. Even if it's a symbol like "init" that's defined in a C++ template; it might find a few it's not sure about, but mostly it can figure out what classes derived from that template and show me just that list, ignoring other functions called "init".
vi can do SOME of these things, but in general only if you jump through a lot of hoops to get it all set up. The last time I tried to configure "tagging" so I could get references, though, it completely failed with respect to templated classes. Maybe it's better now, but back then it worked in SlickEdit and not in vi.
