Hacker News Reader

You have to learn h,j,k,l are not just navigational keys but also can be combined with multipliers like 20h(Moves 20 positions to the left).

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

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.

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 '/'.

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.

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.

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

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.

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

Indeed. Remapping inventory would be horrible.

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.

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.

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!

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.

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

Just use f and ; judiciously.

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.

You can start thinking in vim by reading this answer on stack overflow: http://stackoverflow.com/a/1220118

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.

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

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 :)

Yeah you are right; I use c more than d. The a command is also very useful.

Wow cit...I've been wondering if this exists for a year now. I remember reading about it when I first started learning vim but it somehow eluded me afterwards. Thanks!

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.

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

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

> Wow cit...I've been wondering if this exists for a year now

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

I'm going to try this: inoremap jj <Esc>

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

The setting applies to all maps. :help timeoutlen

You could probably try setting timeoutlen to something like 500 milliseconds (or whatever feels comfortable). Bear in mind though that this is a global setting.

yes you can set the timeout delay to be something very small see :help timeoutlen. It defaults to 1000ms but you are free to change it. If you are typing in insert mode and you press j it will delay but if you press another key that is not bound to anything after j it will just insert the j and the other key.

addendum to the above advice from me:

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 don't know how this would work out ergonomically. My dad is a cab driver and he often complains that pressing the clutch with his foot often giving him RSI kind of pain.

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.

Please read the author's introduction: "An Introduction to Display Editing with Vi" http://www.verticalsysadmin.com/vi/vi_editor__bill_joy.pdf

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

Have you tried running vimtutor? It goes quite a way towards teaching the general philosophy (or 'zen' if you like) behind using vim.

http://www.openvim.com is also a good web-based tutorial that I used when learning vim.

http://web.archive.org/web/20090323065900/http://vi-improved... (no longer exists on the site) is where I picked up the vim model.

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

Thanks for that Zenclavier: Extreme Keyboarding article. I had somehow missed that until now and loved it.

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.

Regarding emacs pinky, many people find remapping CAPSLOCK to CONTROL helps quite a bit. Here is one popular xmodmapping:

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

CapsLock to Escape is something I find useful with Vim. A lot of people advocate mapping it to Ctrl then using Ctrl-c or Ctrl-], but It's better to just skip the middleman I think.

You can also map it to something like 'jj'. I don't use vim that much now but I found that more ergonomic than any of the special keys.

If you're using X, then xcape can map both Esc and Ctrl to Capslock. https://github.com/alols/xcape

Now that is clever. Thanks for this.

You might like my book, Practical Vim. It's now available from the Pragmatic Bookshelf as a beta book: http://pragprog.com/book/dnvim/practical-vim

You can wear driver's shoes. They give stability with the flat heel.