[pix64]

Is scrolling through source code really faster line by line?

[blunte]

There are so many keyboard options for moving through source which you don't have with a mouse...

- Page up/down (and especially with home row shortcuts like in Emacs and Vi)

- Brace match jumps

- n line jumps up or down in Vim

- top/mid/bottom of view jumps

- page shifts up and down without moving the cursor

- top/bottom of file jumps

- jump directly to a line in a file

... and more

Seriously, put an Emacs or Vi power user next to a guy with an IDE and a mouse, and it's no contest.

[chousuke]

As a vim user, I don't really find myself needing to scroll "fast" ever. Instead, there are three common cases:

1) I'm reading through code, and scrolling one line at a time with j/k is fast enough.

2) I'm looking for a specific point in the code, in which case I use search to get to it.

3) I want to go to the bottom or the top of the file, in which case G/gg are much faster than scrolling.

Sometimes I might use Page up/page down to skim a file, but that's relatively rare.

[btschaegg]

Actually, this is also a point worth stressing for people without Vim-experience: Searching is a "first-class citizen" (as the FP-guys put it with functions).

It's only ever one to two keystrokes away. You press '/', enter your phrase, and press ENTER. Stepping is done with 'n' and 'N'. There really are no convoluted hotkeys for this - which means that you do it much more liberally once you're accustomed to it.

Also there's '*' and '#' to quickly find the next/previous positions of the word your cursor is currentl located on. The same thing applies there.

[noctuid]

That's what you do with a mouse though. With a keyboard, you can move by semantic units (like a paragraph or function), use fuzzy search to jump to a specific function, etc.

[ryandrake]

80j

Just scrolled down 80 lines