For what it's worth, I remapped vim's navigation keys from the awkward hjkl to the normal inverted-T arrangement i,j,k,l. Then I remapped the inserts, i & I, to h & 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.

People always treat hjkl as the single biggest roadblock to vi(m) adoption, and I don't get it. Two points:

* 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.

These days, almost all potential vim users have been using the sensibly-arranged arrowkeys for years before they start using vim. Vim puts a second set of arrowkeys right under their fingers, but it has a different, awkward arrangement that makes no sense on a modern keyboard and conflicts with vim's mapping of the real arrowkeys. In vim, the middle finger sits on the DOWN key and reaches up to go up if you are on the arrowkeys (as everyone assumes), but if you are on the home row, your middle finger now means UP instead of DOWN and to get DOWN you go LEFT.

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.

There are two other advantages to using hjkl, that hardly anyone ever mentions:

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!

Am on Dvorak and the hjkl doesn't make any sense at all to the dvorak layout. So i have remapped them to snhd instead, but still i end up moving my hand to the arrow keys. But i now think i should try the up down left right layout. i.e Use c instead of 't' that would help eliminate the flow breaker of moving my hand to arrow keys.

I agree, and getting used to using j/k for up and down also offers the advantage that a lot of web apps are supporting it recently. It is in gmail, google+, github, google reader and probably more, having the habit of using j/k for navigating really helps.

ijkl sounds good, but it would break my habits for when I play nethack...

Indeed. Remapping inventory would be horrible.

I also never used that feature and I've been a heavy vim user for maybe 8 years.

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.

Note: this post assumes Vim, not other implementations of VI

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

In emacs, we do the same with C-s (search-forward) and C-r (search-backward). It is highly recommended to "jump" to the exact text you want, rather than fiddling around guessing and correcting numerical character and line jumps. Just a bit of support from the dark side!

That's interesting. When I used Emacs with the default bindings, I only used C-s or C-r when I was genuinely trying to search for something, not for navigation. I think I normally used an estimation like C-u 2 0 C-n exactly where I would recommend against doing 20j in Vim. [I meant 20j instead of 20h in this post's grandparent.] This discrepancy probably arose in part because I tend to edit documents as I go in Emacs since there's no mode switching, meaning I didn't usually have to do much jumping around in files, and in part because in Vim I'm used to using the /?nN keys as the motion components of editing commands, not just as isolated motions for navigation, so my fingers are used to jumping to places by searching.

Oh, the search feature! In Vim we call that '/'.

Just

  :set relativenumber

You won't have to count anymore.

Not really going to help you for 20h...

Difficult to disagree. However if you use 20h, you're probably doing it wrong and should use w/e/f instead.

Usually, yes. The two places I find myself using a count on h or l are 1) in nonce key bindings, and 2) when there's a lot of instances of what I want to jump to near the start of a long word, followed by a gap without the character, followed by where I want to jump. If I'm faced with www.wikipedia.com/something/wouldyouchangethis it's simple to say 10lfwcw - if I'm off by 5 in either direction it doesn't matter and ballparking like that is easy.

Yep, I'm the same. I do however jump 5 or perhaps 10 lines or words in the general direction I want to move in and correct from there. Other times it's less keystrokes to just hit / and search for the next location.

In my experience, if you are counting characters or lines in regular vim editing, you are doing it wrong. The smarter jump commands, text objects, and a high key repeat rate are all far superior to counting 20 characters. I do use counts a bit with w/W for words. The main advantage is making your edit in a single command so you can reuse it with dot.

Honestly I use stuff like 2W and 5w more likely to move around. I think it's far better than 20h

Right, I use w and b to go forward and back one or two words at a time. For lines, I :set relativenumber and use that as a cheat sheet if I want to move or delete n lines down.

Just use f and ; judiciously.