tl;dr Emacs and vi keybindings are a product of inferior keyboards used at the time of their inception and not (I repeat, NOT) a superior way of text editing which philistines can't comprehend.
Programmers are the worst cargo cultists.
Programmers are the worst cargo cultists.
But you are the boss, boss. Won't happen again.
Give me those "inferior" keyboards any day.
My memory is a little hazy on the "when", but I think some 6-12 months after starting at that company, I noticed my left pinky did indeed kind of hurt. Reaching for that Ctrl-key on the far, far left front of the keyboard was getting a nuisance. The "emacs pinky" was real!
I did a bit of research on the Internet and found a piece of text that said, Ctrl used to be where CAPS LOCK lives now, oh, and here's how to make your CAPS LOCK into an additional Ctrl key (I cannot remember a single time I used CAPS LOCK, so I did not exactly miss it). I made the change and found it more comfortable right away.
To this day, the first thing I do on a new computer I am going to use for longer than, say, a week, is to make that little change. My pinky has not had any problems since.
Incidentally I _also_ switched to Dvorak too, but only for that keyboard. Works great because muscle memory "feels" the keyboard is different and uses the correct layout without cognitive overhead.
EDIT: typo
I have found that having only one C- key on the keyboard becomes uncomfortable over time. For example C-a and C-e and C-x and C-f contort my hand more with only a left hand C- key...looking for this in a keyboard is one of the things I learned from Xah's site.
Yes, I might be a special snowflake — most developers don't have problems with vim or Emacs, expect for occasional flame wars between the two. But I do, even as I tried to make the switch like 20 or more times.
What I like about Emacs is that I can use it with just about any programming or semi-programming language I come across without having to learn a new IDE or editor. The other thing I like is that the capability ceiling of the tool is so high that I am constantly making significant progress in terms of efficiency. So the cost of learning it, was and is worth it for me. If I was writing Java or C# or Pharo most of the time, I'd probably uses different tools.
The situation changes drastically once you account for two things:
1. The plugins. I said it many times already here on HN, but my Emacs is running 900k loc of Elisp, where more than 500k loc are plugins (or extensions, applications, and libraries). When modern packaging systems appeared, for both Emacs and Vim, their ecosystems were already formidable - it only got better since then.
2. Customization. It's not, in my opinion, worth learning Emacs if you're not going to customize it. The defaults are awful, that's one of the few things I agree with Xah on. But the ease of configuration and extension makes up for it if you're willing to put some hours into it. Not into "learning Emacs", but into "learning how to customize Emacs". The latter - if you're a programmer - is also more fun than memorizing arbitrary keybindings which don't necessarily make any sense for your keyboard, hand size and other factors.
It's, of course, a trade-off, as you have to put some effort into it and you're starting from a rather low point. You could try one of Emacs "starter kits", but, honestly, they involve just as much memorization as the vanilla version and (as mentioned) I don't find it fun at all.
Still, the smoothness of your workflow that you can achieve with Emacs once you do customize it is astonishing. It's still not pretty like VSCode (just one example I recently played with), but it doesn't have almost any limitations to what it can do with a single press of a key. It can make minutes or sometimes hours of your work time collapse into seconds (well, as long as you tell it how).
If you didn't already - if anything I wrote here is news to you - you could give Emacs another try. Of course, if you're not opposed to spending some time tinkering with it until it feels just right.
However, I have also seen mention of people remapping return to the right control key, then doing who knows that to still be able to press return.
Speaking of touch typing, the TrackPoint between g and h is also helpful. Thinkpads and Dell Precisions typically have one. Some Toshiba's also. Though this sort of assumes that keyboard is a primary driver for a laptop purchase.
And you can still use right control when typing a letter with the left hand. When pressing control-<right-hand-letter> you have less stretching. I've subconsciously over time found that I mostly do single-handed cording with control-<left-hand-letter> though since the control location is so much more convenient than the shift location (for me). Your milage may vary!
Mapping caps to control makes my keyboard a bit more usable, but it is still fundamentally flawed in a variety of ways.
That is probably one of the reasons ergodox (or similar) is so appealing to me.
Note that moving your hand to the arrow keys is, while more intuitive, slower and requiring more thought than the other options presented (once these options are learned).
(I am a proficient touch typist, but I can't adapt to hjkl in lieu of arrow keys — not to mention the context shifting overhead for two vim modes).
Side note: TWO vim modes? I guess you're never had the pleasure of stumbling into ex mode
Control keys are relegated to the edges of the keyboard and easily remembered and distinguished by touch, as there are only few of them. Cmd+X, Cmd+C and Cmd+V is much more convenient, memorizable and logical (X and V visually look like editing marks on paper, for cutting and inserting respectfully; C is for Copy), than... how do you copy-paste again in vim? v/y? I see no logic there. Yes, I remember that v is for "visual selection", and y is for "yank", whatever it is... but it is way less logical.
The swap of del and '\' is annoying too, and creates problematic muscle memory that will fail you when you're forced to use a normal keyboard.
http://www.pfu.fujitsu.com/hhkeyboard/leaflet/hairetu.html#l...