Vim esckeys (opens in new tab)

Having remapped my caplocks key to be escape, I find myself using it fairly often not just with vim but in all sorts of ways. Considering I never used it as caplocks before except accidentally I found the remapping a good investment.

Instead of Esc you can use Ctrl-C without any delay. I learned this years ago when the latency of a satellite Internet connection would interfere with Esc and Meta.

And, if you remap Caps Lock to Ctrl, Ctrl-C will be easier to type.

This works 99% of the time. The only exception I know of where it performs differently is in operations on a visual block (not visual line) selection -- hitting Ctrl-C only applies changes to the current line but Esc does what you want.

I'd wondered why hitting 'O' after hitting escape led to such a nasty delay when running vim in a terminal. Now I know.

For those that still want arrow keys in insert mode (sacrilege! ... but I do), this is probably the .vimrc option you want:

    set timeout timeoutlen=1000 ttimeoutlen=100

I forgot all about this problem ever since I remapped 'jk' to <esc>. Although when I was primarily using <C-[>, I tried the timeoutlen and ttimeoutlen solution but couldn't really find any values that didn't conflict with my preference of delay allowed between entering personal map key sequences (other than the default, which is what partially causes the problem).

To the OP, Thanks, I knew why it was delaying but didn't realize I could disable the behavior!!

The leads back to the very old days of serial terminals and the horrible ^[ prefix in many terminal's function and arrow keys. I remember fondly working with Wyse60's and some other terminals that used ^A instead.

Imagine trying to detect ^[{randomDelay}O{randomDelay}C -vs- the user typing ^[{randomDelay}O

The Wyse60 used left=^H, right=^L, up=^K, down=^J so there was no need for the delay to detect the sequence.

Back in the old days Vi would detect this lack of multi-character function keys and not use a delay.

On a 1200 baud modem it was very nice however later as DEC and ANSI multi-byte sequences became more popular this became much more painful.

See: http://en.wikipedia.org/wiki/Termcap for more terminal insanity fun.

On a fun note, I have a customer with a 1987's era copy of Microsoft Excel for Xenix (yes it really existed).

Each time we upgraded their system to a more powerful cpu I had to patch the binary as it literally used a spin loop to delay long enough to detect the keys (never mind tty settings can help with that at kernel level). The last time I had to make it work on a recent core I literally set the "spin loop counter" in the millions to get it to work via telnet on a local network where they keys come fast and low latency!

It took me a couple hours the first time with a debugger to find this little gem, so I have a README in the binary's lib dir that explains how to update it. Every couple of years I have to dig in and figure out the right value! Fun!

EDIT: It's possible the magic was actually happening in termcap with the original vi. I didn't dig into the source to verify. :)

Note that you don't actually have to wait for the delay to start writing. If you press <Esc>O and just start writing during the delay, vim will "cancel" the delay immediately (but of course, if the first letter you type is, for instance, a C, Vim will think you pressed the right arrow key and so on).

I only just figured this one out myself a few days ago. Another alternative is to map jj or jk (or whatever) to esc in insert mode. Then you just need to get out of the habit of hitting esc. Of course, then there's a delay on hitting j but I've found it less of an annoyance.