You know, I've understood this for a while, but to this day I still don't use it.

I can't count characters that fast! If you're going to lean forward and count out chars, you might as well count them out with presses of 'h'.

With that, my natural finger movement on the arrowkeys and on the vim home row match each other.

The reason vim's navigation keys (hjkl) today are arranged the way they are, left-means-down and right-means-up instead of up-means-up and down-means-down, is among the dumbest reasons there can be. Decades ago, the keyboard Bill Joy happened to be using when he wrote vi just happened to have arrows printed on the keycaps of the hjkl keys. He was trying to think of ways to make memorizing lots of commands easier, so he decided to take advantage of what was printed on those keycaps. There were no arrowkeys on that keyboard. That, in itself, was not a dumb choice, because it would have been a useful mnemonic on his own keyboard and he'd probably never seen an inverted-T set of arrowkeys, which didn't become popular until years later.

The dumb part is the insistence on maintaining this onion in the varnish as sacrosanct decades after that silly keyboard disappeared and in an era where every new vim user is accustomed to using the inverted-T arrowkeys found on virtually every keyboard. Anyone who, for some reason, hasn't ever used his arrowkeys picks it up immediately: up-down-left-right mean up-down-left-right. Got it.

That's why so many people who want to use vim have to be "broken" of the habit of using the arrowkeys and forced to learn an additional, weird arrowkey arrangement, because ("trust us") using the home keys is better.

Well, using the home keys is better, but not because of the awkward arrangement. That part is worse. It's better because that's where your fingers rest normally on the keyboard, from where you can operate the full set of vi commands and enjoy its full power.

You can have both. It wouldn't take much convincing to wean people off the arrowkeys if both sets of "arrow keys" on their keyboard had the same natural arrangement they've been used to for years.

I was worried when I abandoned the onion that it would handicap me on plain-vanilla installations of vi/vim until I realized that, these days, yes, there are two sets of arrowkeys on every keyboard, and I can use the real arrowkeys if I have to work on a version of vi/vim without my .vimrc, because they're arranged just like my ijkl. I can live with using the real arrowkeys for a while, and if I'm staying longer, I'll "curl -O mydomain.com/myvimrc" and restart vim with my full customizations and go back to the home row. (I also have my zsh in vi mode, and my .zshrc remaps keys the same way and can also be fetched using curl.)

I fully understand that changing this fundamental arrangement is NOT attractive to experienced vim users, because muscle memory has long since automatized the arrangement. The old fogey's vociferously defend the old onions for various, mostly self-serving, reasons.

(They tell me, for example, that this will make it impossible to use a vim on a different machine on the same page where they brag about their extensive and brilliant .vimrc customizations that they "couldn't live without." Hmm.)

But I'm starting to teach my kids to use terminals, command lines, and editors, and I didn't want to pass this onion on to their generation. I remapped the keys and retaught myself to make it easier for them. Now we can share the same .vimrc and .zshrc. They'll have one, consistent set of muscle habits for arrowkey motion from the start, whether playing games, editing text, or on the zsh command line.

* First and foremost: If you rely on hjkl, you are doing it wrong anyway. You should be using f, w, ), :n (for integer n), ^d, ^f, etc. My biggest hjkl use case is using j to idly scroll through a file (or less/more/man page), in which case it's conveniently under my index finger and I love it. I also use l for off-by-one errors.

* Secondly...especially now that it's ingrained, all of the other keys "make sense" (sort of), and there's no excellent alternative. With your setup, "Why is h insert? Wouldn't i make more sense? Gosh, vim is hard to use." Etc. etc.

Yet you "don't get" why that might be a problem for people? Really? If it is what you claim, "the single biggest roadblock," then there is something important here, whether you get it or not.

You argue that if you rely on these awkward arrowkeys, "you're doing it wrong anyway." Does that mean they don't really matter? If not, then the using the most prime of the keyboard real estate for operations that "real programmers" don't have much use for would be an even worse design than I'm claiming. If they are important enough to dominate your right hand home row, and I think they are, then your argument is meaningless and they ought to be rearranged so that this no longer "the single biggest roadblock."

And this second reason is silly. Training your finger to reflexively move left instead of up to insert text to the left is going to be a challenge of the same magnitude as relearning arrowkey movement? You think so? People who have been using "copy" for years have to learn that copy in vim is called "yank" and the t,T commands mean, well, "till", and you have all sorts of ctrl-* and meta-* commands to somehow learn, but having to learn to use h instead of i would be such a hurdle that it's really a show stopper for fixing the arrowkeys? That's really your second strongest argument?

These aren't real arguments. Long-time vim users argue that one of the glories of vim is its marvelous customization, but if you customize the basic movement keys, it's supposedly a horror because, well, you then won't be able to use a non-customized vim. So, what's the customization for? It's for secondary things, not something so fundamental. Then you're told by someone else that, besides, if you are using the movement keys much, you're not using vim correctly. Which sounds like a claim that the movement keys just aren't fundamental. And if they're not, what's the problem with customizing them.... What a bunch of nonsense.

It's all a smokescreen for maintaining backward compatibility with a poor design that has spread, mostly in the heads of old programmers (the ultimate "legacy systems"), but also into some software. But for those willing to admit that backward compatibility is the only real argument, think of how much MORE legacy there is these days for the real arrowkeys in the minds of non-vim users and in software of all sorts.

I think vim should change its defaults. It probably would if it were a commercial product, but that won't happen, because defaults in vi/vim are by and for long-time users, not potential users. But it is, as claimed, customizable, and so are most systems (like zsh) that have a significant vi-mode. Systems that don't have a serious vi mode but just toss in a couple of shortcut keys, like j&k, can be learned ad hoc, the way we have to learn all the other shortcut keys that have different meanings in every program.

So, I'm customizing vim & zsh, using the real (physical) arrowkeys occasionally if connecting to a plain-vanilla vim/bash, and it's working out just fine.

1. Ctrl-H is Backspace, one of the most used keys, and much more conveniently placed than, er, Backspace. It's right next to the index finger. It's intuitive (in vim) because H is "go left". Ctrl-H works everywhere, in the shell, in OS/X all over the place, it even works in the Windows shell. It's some sort of fundamental mapping to Backspace such that can't actually be re-mapped.

2. Ctrl-M is Enter, another one of the most used keys, and also more conveniently placed than Enter. As with Ctrl-H, it fits under index finger, it's an ancient mapping, underrated, works in lots of places, even in Windows shell.

If you use the crappy arrow keys, your fingers are totally in the wrong place!

Thanks to the relative line numbers patch being merged in finally (:set rnu and now you show line numbers relative to your cursor) you get easy moving up and down.

I prefer the easymotion plugin (https://github.com/Lokaltog/vim-easymotion/) that annotates your file with little markers (like the vimperator/pentadactyl/vimium browser plugins use to click links with the keyboard) that allow you to jump around extraordinarily quickly.

It was, and still is, a learning curve since it adds to so many basic vim commands that are muscle memory for me by now but it's worth it.

If you type fast, you don't want to have to spend time correcting for line estimations that are slightly off as a result of thinks like 20h. For navigation, just use forward slash to search and you'll land right where you want. It's also almost always faster to use f/F/t/T in conjunction with semicolon or comma for jumping to specific letters than using h or l. The # and * keys are also useful for jumping to words in a specific line. Failing all of /?fFtT#*, it's still going to be faster to use ^0$wWbBeE than hl unless you're one or two characters away from where you want to be. But you shouldn't even need to navigate much within lines, since text objects let you edit entire units of text, regardless of where the cursor is within those units. People who come from an emacs background (and use the default editing environment instead of evil) can't even imagine how powerful Vim is as a raw editor until they try it. I can only edit in emacs for long periods of time if I'm using evil to emulate vim's text objects.

See http://www.viemu.com/a-why-vi-vim.html if you're new to Vim

  :set relativenumber

Moving word wise,(w,e) is used a lot.

Next occurrence of word under cursor is useful. *,#

Learning effective macros is extremely useful.

di" is one of my favorite commands. Delete everything inside the quotes not including the quotes.

Put inoremap jj <Esc> into your .vimrc so that you can press jj quickly in insert mode instead of Esc.

Remap your arrow keys to nop and get proficient with it; this feels like I am editing super fast. A lot of editor time can be spent with your hands on home row without ever leaving.

You usually want to replace what's inside the quotes, so hence use ci"

cit is pretty nice for replacing a tag's inner html. And of course this works with parentheses - ci( - and brackets - ci[ - and curly braces and single quotes and angle brackets.. I love vim :)

I use ci{ all the time for functions and CSS. It's like magic. Whenever I'm using something like nano, I'll instinctively type what looks like a long string of gibberish: "jjjddo [oh crap] <bs><bs>..."

Once you really start getting used to the language, it makes it frustrating to use anything else.

Then marvel at vim-surround: cs"', cs)(, or cst<foo>, or (Shift-)v select visually S <mytag>, and argtextobj: cia and daa. Those are the two plugins that I really miss on a stock vim.

[0] https://github.com/tpope/vim-surround.git [1] https://github.com/vim-scripts/argtextobj.vim

Indeed... That is why I have been contributing to Xvim[1] for Xcode it's so nice to have vim bindings in Xcode.

[1] https://github.com/JugglerShu/XVim

I normally use C-c. Is there a way to make the time between j...j to be really short? Like the delay for it to count as a double press? I'd like to reduce any chance of accidental typing (although I can't see any reason I'd type "jj" a lot).

How could I forget the substitution command? <range> s/old/new/g (g == all occurrences on the line.) range can be a lot of different options. The most useful <range> options in my experience would be:

%(all lines in the file),

select something in visual mode and press :,

-x, +y for + and - x and y lines from where you are.

exact range is not that useful in my daily use.

The other thing to note about the s command is that you can use other delimiters instead of / I like to use #

% s#/some/path/to/a/file#/another/path/#g works just fine and is much more readable than % s/\/some\/path\/to\/a\/file/\/another\/path\//g

I think the car clutch is more related to the force required to press it - it's kind of a long, slow push with lots of pressure AND control at the same time. This seems like a button, on/off-type deal - more like tapping your foot than squeezing a clutch.

I also recommend the O'Reilly "Learning the vi and vim editors" book, http://shop.oreilly.com/product/9780596529833.do and my own course on vi basics, http://www.verticalsysadmin.com/vi.htm

It looks a bit untidy, but it's a very quick read because it's a low-density chat log.

Wonderful articulation of what we're losing with the fashion moving towards low learning curve, expert-proof designs.

Now I can send that link to people instead of trying to articulate the same idea in my own words.

  remove lock = Caps_Lock
  remove Control = Control_L
  keysym Caps_Lock = Control_L
  add lock = Caps_Lock
  add Control = Control_L