Gah, the tutorial keybindings! They are mad. I've been using emacs for a very long time, and I can't imagine using those to navigate. Emacs has perfectly reasonable default keybindings these days, they just aren't the ones mentioned in the tutorial.
Usually the strong defenders of emacs tell you that you must use c-n c-p c-b c-f to move because those are better and you will adapt in a short time.
Then the strongest defenders of emacs tell you that you must use whatever you want because the purpose of emacs is that the editor must adapt to you and not the opposite.
Actually I think the strongest defenders of emacs say you use C-s and the like for most navigation. Moving character-by-character is slow and inefficient, so the argument about whether C-n C-p etc. are better or worse than hjkl is irrelevant.
I have my own code editor which is more like vi than emacs, but I'm using interactive search in it.
It's the vim defenders who will claim that the home key navigation is a must. Emacs advocates don't much care from what I've seen. Some of them will be roused to suggest that you learn to use searching better.
Vim defenders will also tell you to use search. Also, why would even Emacs fans recommended corded combos over single keypresses? Give my pinky a break man!
Because it means you don't have to jump in and out of different modes. The biggest thing that kept me from using vim was _constantly_ typing in normal mode and trying to issue commands in insert mode.
Is constantly hitting the Escape key (even remapped to Caps Lock, or using ^[) really any better on your pinky?
I use ^[, and I use my pinky a lot less than I would in emacs, because I do a lot more in command mode than I do in a single emacs chord. I view "insert some text" as its own command. Vim's commands are structured so you can combine orthogonal pieces, where emacs has a separate chord for everything.
Vim does the orthogonality thing better, I'll admit, but Emacs' separate chords tend to follow useful patterns, too.
For example, moving forward a character is C-f, moving forward a word is M-f, and moving a balanced expression forward is C-M-f. Same with b for backwards movement. C-a moves to the previous beginning-of-line, C-e to the next end-of-line. M-a and M-e do the same with statements in place of lines.
I can't even remember at this point how much of this is standard, but I've replicated the forward/backward movement for killing: C-d deletes a character forward, M-d kills a word, and C-M-d an expression. C-h deletes a character backward. Guess what M-h and C-M-h do.
Of course, both editors let you do basically whatever you want, so really the text input issue is just one of whether you prefer chording or modal input. And I'm not saying modal input isn't useful; Magit's input system is closer to vim's than to the rest of Emacs, as is Ediff's, and I like it that way, but I prefer chords for editing -- less state to hold in my head.
Sequential chords, though, like C-c C-v C-d, are right out, and using C-n and C-p and co. for up and down sucks, especially when I try to use M-p to select the last input in minibuffer history and hit M-o instead, prompting me to select Bold, Italic, or Other. I'll change them eventually; the hardest part is deciding what to replace them with.
/aimlessramble. I guess it all just boils down to "Use the tool you can best configure to work the way _you_ want it to." I think the linked article was trying to make the case that Emacs can be that tool for vim users.
At least it's a "home-row pinky" with Emacs' Ctrl, too. :)
Personally, though, I don't find the worst strain comes from the placement of Ctrl. The worst comes from the awful staggered layout of keyboards that serves no purpose save for a long chain of HCI backwards compatibility with the typewriter. I hope someday keyboards like the TEK (which, incidentally, gives a perfect spot for Alt or Ctrl under the left thumb) become more commonplace, or eye movement-based systems supplant the use of one's hands for focus control.
Hm, fair complaint. At some point I found that hitting ESC immediately after typing became habitual. I find myself accidentally doing it outside of vim quite frequently. I've heard others make similar statements to yours, though. If rebinding to a different key doesn't solve it, then modal editing may not be for you.
I'm a fan of C-n and C-p; I often find myself using them even in Sublime Text or other editors (even in a text area on a web page). But for some reason I find C-f and C-b much more obtuse. Part of it is that in a QWERTY layout, "f" is to the left of "b", and yet "f" moves the cursor to the right. Also, assuming you press Ctrl with your left hand, "f" is more natural to use with your left hand, while "b" is a bit of an awkward reach, making it natural to use the right. This left-right switch is awkward, especially combined with the aforementioned direction reverse.
On the other hand, C-a and C-k (especially in combination with each other) and C-e are incredibly useful, and once I discovered them I immediately started using them everywhere.
The nice thing about the C-{n,p,f,b,a,e} is they work on the bash shell command line by default. So learning them is actually really useful, even outside of emacs.
I use the arrow keys in both Vim and Emacs. There are enough keys to remember (most of which I forget all of the time... like paging up and down, have to look that one up every time) that I don't need another set of keys to remember. Arrow keys work just fine.
Tell you the truth, I've used Emacs for a long time now (~10 years) and I don't know if I use the C-{n,p,f,b} or arrow keys. I'm more likely to move in larger chunks: search, move by word (M-f, M-b), line (C-a, C-e), etc. If I need to edit a word, I will kill it entirely and re-write it.
same exactly for me, i use sometime the arrows or the other keys or c-s etc.... i don't mind the jk vim keys as well when i am in vim, either way it's all about your brain being good enough to context swift in .... context
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.
Why? Isn't that more inefficient because you have to move your hand off to the side. I can type 3 C-n before moving my to the right to do a single down arrow. Maybe I am just used to it by now, and forgot how hard it was when I started, but it makes complete sense to me.
that's the old-school Starcraft way. try mapping caps-lock to control sometime, just to see, it's such wasted real-estate. nothing beats muscle memory and years of practice though.
Caps-lock as control is a nice but unsymmetrical mapping. If you want to avoid pain you might want to use the opposite hand to hold control while hitting a key combo. At least, this is what works best for me. I never have to twist my hand into unnatural positions.
I stick with the default emacs key bindings because many of them work outside of emacs. Muscle memory has me constantly using C-k to kill a line for instance, and this also works in Mac Mail and Safari.
Command: move down one line
What vi uses: j
What the emacs tutorial suggests: C-n
What I use in emacs: the down arrow