Thankfully I am blessed with the ability to move my forearms.
I've heard a lot of people talk about keeping their fingers on the home row, and I more or less do that when I'm typing text like this, but for general navigation? I've sat next to a number of people who do it, and I get around my editor faster than they do. Based on this anecdotal evidence, I don't think moving my hand a short distance to reach another key is a significant speed cost.
Then how do you move multiple lines at a time (4, 16, 64, 256)? To move 16 lines down, I press C-u C-u C-n (of course, the control key stays down the whole time). You either have to press C-u C-u then move your forearm to the arrow key and press down, or press the arrow key 16 times.
(Each C-u is a power of 4. You can specify any number by typing it after the C-u, for example C-u 100 C-n to move down 100 lines.)
I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines. What I invariably want to do is "move down one paragraph" (C-down) or "move to that spot I can see on the screen" (1-6 lines, tap up/down; 6-30 lines, hold the down key for about a second until I'm within a line or two, then tap up/down a couple times; >30 lines and use pgup/pgdown to get closer). For anything further away than that, I'm going to use isearch to get closer.
Sometimes I want to make a complicated motion in the horizontal and vertical axes at the same time in a context which is not well-formatted source code and hence has no good paragraph/word landing points. For this I move my hand slightly further and grab the mouse. It always amuses me watching people try to do it "the right way" and then spend 30 seconds trying to work out what sequence of buttons will get them there, then spend another 30 seconds remembering what they wanted to do when they got there.
I'm not trying to minimise the number of logical keystrokes, I'm trying to minimise the time and distraction of navigation. A few simple operations combined with key repeat seems to work really well. Lots of people seem to neglect the power offered by key repeat.
I'd love to meet somebody who could navigate source code faster than me and learn how they do it. When I do, I'll probably change my approach. However, I've worked with a lot of different people who used a lot of different approaches (yes, including that one where you display the line offset from point and type the number of every jump) and in the past decade I have not found any of them to be faster than me - although I have found a few who were roughly the same speed.
> I cannot recall the last time I wanted to move 16 lines - that would imply I stopped to count the lines
I'm sure something like this is possible in Emacs, but in vim I have it set up so that my current line shows the absolute line number and other lines show the relative line number.
If I'm eyeing a particular line that I want to jump to, I just read off its relative line number and hit j or k, according to whether it's down or up from where I'm at -- I'm there. Because I use relative line numbers, the number is never more than two digits.
For more precise navigation (jumping to a particular spot on a particular line), I use a plugin called EasyMotion, which basically lets me jump to any text object on the screen with a few key strokes.
I like the idea of knowing relative line numbers, but I have been unwilling to relinqish seeing absolute ones due to how prevalent it is to see them -- diffs, linting errors, and stack traces often include line numbers, and I find it really helpful to be able to easily find that. Go-to-line is supremely useful, but I also find the visual reminder helpful as well.
In VS, I use VSVim which lets me actually have both absolute and relative line numbers, but it probably wouldn't be difficult to write a vimbinding to bind enabling/disabling the line numbers plugin to a chord/hotkey.
This seems to be one of those arguments where we programmers tend to optimize for the wrong problem. Sure, we may be able to input more text more comfortably with the merits of one text editor over another, but really, I think most of the time spent during programming is reading APIs, headers, other code and most importantly thinking. Typing is hardly the bottleneck.
Except when it is... If you can edit fluently and quickly, _then_ coding is more of a nonissue, you're free to try things out, you can find and fix an error and Alt-Tab without blinking, you can harness this kind of physical flow of noninterrupted work, etc. I've worked alongside programmers for whom typing and editing were indeed quite the bottlenecks. Of course, any programming editor is probably good enough if you learn it.
Agreed. I don't know how anybody could use vi with escape unmapped. It's also very useful outside vi though, since esc is the default 'cancel' key in many cases. For example, most browser dialogs (and keyboard-navigable menus) can be closed with esc, and it works for many desktop dialogs too (at least on Linux).
The more common remap is probably capslock->ctrl, for both vim and emacs users, I but I definitely prefer capslock->escape. During normal operation, my left pinky rides the gap between a and escape(aka capslock). Pressing either requires the slightest of deflections to the left or right.
I keep escape as escape as well. Capslock is absolutely worthless to me.
Or use PCKeyboardhack and I forget the other plugin but on a Mac, I have a brief caps lock mapped as esc, but holding it is control. it works effortlessley.
On my chromebook pixel, there is a super/windows key (labeled as a "search" key) where the capslock normally is on a US keyboard. Since I use super as the prefix key for all of my window manager shortcuts, I use xcape (https://github.com/alols/xcape) to allow that key to function both as super (if I hold it down) and as escape (if I tap it).
These sort of systems are a great way to remap keys; I wish such remapping was exposed by operating systems in a nice stock way.
