Emacs more likely since the bug is 23 yrs old and the gatekeeping

But yeah I agree with the sentiment of parent OP

> Was that expressly written to parody Vim?

Yes. The advice to turn the yoke upside down is supposed to reference remapping Caps Lock to Escape, without which Vim destroys your pinky on a standard keyboard. But it's the choice of professionals, so what can we do?

Nice, I didn’t pick up on that one. And yes I do have Caps Lock mapped to remapped to Escape haha.

If any vim enthusiasts haven’t read this history before, this article [1] provides a good overview of how ex/vi came to be. The photo of the Lear Siegler ADM-3A keyboard used by Bill Joy largely explains the odd choice of keys.

[1]: https://twobithistory.org/2018/08/05/where-vim-came-from.htm...

I'm playing into the joke here, but on most terminals, alt + <key> will actually be sent to the program as <esc> + key. You can use this to avoid pressing escape in Neovim.

Interesting tip too! Need to find the right combination however, I noticed that Alt-L might be a good one (no side effect it seems).

That will move your cursor to the right by one character after exiting insert mode.

Entering + exiting insert mode with i and Esc moves your cursor to the left by one, so I suppose this neutralizes it?

+1. I mainly use this approach. If your next intended move is to go to the next line, Alt-J will exit insert mode and go to the next line immediately. Also the same for Alt+w/W/b/B, Alt+o, Alt+0, etc etc and it's just a matter of using your left thumb at the same time as navigating.

Trick for those wanting caps lock to be compose instead: ctrl-c also works as escape, and has historically been slightly faster due to sidestepping the escape timeout.

Wow super useful, didn't know that.

Note that however crtl-c and esc are not strictly equivalent: if you do esc or ctrl-c, the position of the cursor when back in normal mode will differ. You can see this if you do insert then esc repeatedly, seeing the cursor moving. Cursor doesn't move with ctrl-c (which somehow I prefer).

I've remapped caps lock to ctrl with chords and escape when clicked alone. Feel it's the best of both worlds :)

<c-c> is not completely equivalent to <esc>. For example, 50i=<c-c> will insert only one equals sign.

But remapping Caps Lock to a combination Ctrl/Esc is so convenient, regardless of Vim!

I've been using Ctrl-[ instead of Esc for so long that I forget that a lot of people don't know about it. This may not be convenient on non-English keyboard layouts.

More alternatives: https://vim.fandom.com/wiki/Avoid_the_escape_key

small fun fact: I switched to this when the escape key was taken from me (thanks again NOT apple) After switching to a newer MacBook that has the escape key I did not start using that again, but stuck to the Ctrl-[ as it just works.

Better yet, remap CapsLock to Ctrl.

What about control+c? Also, I've never used vim without remapping `jj` to <Esc>.

Ctrl+C and Esc do not behave the same in all contexts. The correct replacement for Esc is Ctrl+[.

What if you need to type `jj`? Not uncommon to do so while writing math or physics papers. a_{jj}

Spacemacs defaults to fd, I don't think I ever accidentally left insert mode with that.

Happy vscode user these days. If I find myself fiddling with an editor it's a huge red flag to me that I hate what I'm working on.

fd sounds much worse as now you can't jump to d characters.

False. The fd mapping would only apply in insert mode. Jumping to d only occurs in normal mode.

Oops - you're correct, of course.

I still don't understand how these mappings are good.

What if you need to type "fd" in insert mode? Like fd0, fd1, etc. Isn't that going to be a pain? Do you never have to type "fd"?

There is a timeout on multi-key mappings, so if you need to type fd0 you type f, wait 'timeoutlen' (1 second by default apparently), then type d0.

That's a pain, but it doesn't come up often. In return you get quite a lot of functionality (due to vim being modal) without having to move your fingers beyond the letter keys, which is quite relaxing.

Having fiddled with file descriptors, I could never live with such a remap. To each their own :)

Not using this personally but there can be a timeout, or you do jk<backspace>j. Fine if the letter sequence is rare enough.

Type "jj" a little slower if you don't want it to be <esc>, it works fine.

I think jk is a bit easier to type but they both work well!

Not sure why you're getting downvoted, repeating the same key with the same finger is slower than dropping two fingers down onto `jk`.

Aaaactually… professionals map jj to Esc.

JJ Abrams disagrees, though.

Depends on how fast a typist he is.

Remapping Caps Lock to Ctrl is a life changer in any environment. Seriously, just try it. It makes a useless key actually useful.

But I use caps lock. Sometimes.

Maybe I've just grown blind to this, but how is this relevant? Unless you mean that you can define that

Frankly, this is sidetracking the topic a bit, but that's one of the things I hate about Vim.

The freaking movement keys. The amount of rationalizing about them is INSANE. CRAZY. MADNESS. "Touch typing"/"more efficient"/bla bla, with 0 studies backing it.

Why do I say this? They shouldn't be in a line. No mass manufactured device in the last 30+ years has them in a line. They're... you know, up is up, down is down, left is left and right is right. Yet some people will defend the setup to their deaths.

And the reason they're like that is... because a terminal 50 years ago, that probably only sold tens of thousands of units, at best, had the setup like that to make it cheaper to produce:

http://xahlee.info/kbd/history_of_vi_keys.html

It's basically the QWERTY keyboard story all over again.

Backwards compatibility is a major pain in the neck.

the bindings are by far the best thing about Vim

In what world are HJKL better than say, HUJK or WASD?

They're just dumb but people have been beaten over the head with them for so long that Stockholm syndrome is SUPER strong, as proven by these comments.

Do you still use a QWERTY keyboard? Or have you just been beaten over the head with them so long that Stockholm syndrome is super strong?

Did you read my original comment? I literally mentioned QWERTY as another example of backwards compatibility screwing everyone over.

I use QWERTY because I have to, I don't like it and I can't do much about it in practice. People frequently defend Vi's HJKL vehemently - just like - if I'm not mistaken - you, presenting it as a superior option for some reason.

As if there are "studies" backing the claim that arrow keys are easier to use for navigation than the home row keys...

Personally I don't want to move my hands from where I'm writing to the other side of they keyboard just to move the cursor.

Like many things in our field, we try to justify our choices, and because generally folks in our field holds high standards about themselves, we should justify as the only right way. What in reality, it is all about user preference.

In the end, use whatever your feel most comfortable. I hate the VSCode interface and all of those notifications/popups and general slow interface, but I can understand who doesn't care or think that even with those VSCode is still more efficient for them. I also can completely understand the issue that folks say when they lost a long time tuning their Neovim configuration to their preferences, considering that I just have done so. But I still prefer neovim to VSCode nowadays, and not everyone needs to think the same, and this is fine.

I take it you've never played a fast game with keyboard controls? :-)

They could have laid out the arrow keys WASD style. One up, one mid-down, two to the sides.

Nobody said they had to use dedicated arrow keys. Just lay them out like a normal human being. Whatever key for up should be up, whatever key for down should be down, whatever key for left should be to the left, whatever key for right should be to the right.

HUJK, for example. WASD is the standard example.

In the specific case of text editing with vi bindings, having up and down on the same row is more convenient, since you don't have to move your fingers to perform linewise vertical motions (compared to a standard WASD "grip"). Navigating within a line using left and right is uncommon when using vi bindings, since there are usually better ways to jump between locations within a line, so it makes more sense to pay the cost of having to move your fingers in this case.

Not only that, but I posit that any context that uses vi-style binds uses vertical motions much more often than horizontal ones (pagers, editors and other applications with vi bind ports, etc.).

As for games, whilst WASD might be more intuitive, it is technically inferior in tactical shooters, where having the W and S keys on the same column means your (admittedly somewhat rarely used) forward-motion counter strafe will always have an inherit delay due to having to move your sole finger dedicated to those two keys. In this case, vi-style ASDF is again marginally better.

That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.

> That being said, your gripe seems to be overstated, if this is your biggest problem with vi-style binds.

I like their composability and I'm generally fine with them, the real Vi problem is just... bad embeddability. Almost none of the apps that I'd want to use with Vi bindings support them to a native Vi level (Firefox - it used to support them well but then they killed the extensions; shells with Vi support only have half baked support, same for IDEs, let alone stuff like Outlook and whatnot :-) ).

Their lack of ubiquity will always doom them to a niche thing used by devs and sysadmins, sometimes, and only by some of them.

This is a point I completely agree with. Firefox is the perfect example of a context where you would want vi binds, but the implementation ends up being half-baked.

The fun part is when web apps like GitLab, GitHub and my email provider provide their own keyboard-centric, vi-style navigation layer, and I have to compromise between either using my browser extension's vi layer or the web app's one.

Nyxt and qutebrowser try to tackle this by offering a native, keyboard-centric, vi-style navigation model - though neither is (yet) a full-featured replacement for Firefox or Chromium-based browsers.

For IDEs, I find the emulation to be alright for basic editing, falling apart soon after. There is an implementation for VSCode that is actually pretty good, as it makes use of Neovim as a backend server - though, it's of course not perfect, and customizing it is a pain I imagine.

Perhaps somewhat ironically, Emacs's evil mode is the best vi layer implementation I've used - probably mostly because customizing it in elisp is much nicer than interfacing with arcane vim APIs.

The vi emulation really is only as good as the implementation. The problem is that it has to be reimplemented for every context, and made to play nicely with the limitations and edge cases of said context. This is, of course, a lot of work.

Check out Qutebrowser. It's almost entirely usable from the keyboard only using vimlike bindings. Lags behind chromium/qt a bit for the actual engine, but these days it's totally usable and has become my daily driver.

Exactly, use arrow keys and be happy, I do it too

(I wouldn't blame vim so much, but more the vim greybeards who think they're still using a 70's terminal)

I actually switch back and forth and I've thought many times about remapping u and l and j and k... you know what, maybe I should just bite the bullet.

HUJK instead of HJKL, basically WASD moved to the right :-)