Vim esckeys(ksjoberg.com)
ksjoberg.com
Vim esckeys
http://ksjoberg.com/vim-esckeys.html
7 comments
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:
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=100imurray, I will update my blog post with the given settings.
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.
I wish I could.
I'm using an U.S keyboard layout and need the ability to write ÅÄÖ sometimes(I'm from Sweden). I've customized my keyboard layout to switch three keys when caps lock is pressed.
I'm using an U.S keyboard layout and need the ability to write ÅÄÖ sometimes(I'm from Sweden). I've customized my keyboard layout to switch three keys when caps lock is pressed.
[deleted]
Same here. I found that having Esc in the home row is really, really convenient, not only for Vim.
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.
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.
It's not well-explained in this article, but the problem is that when press a key like O in normal mode (to insert a line), vim will wait a certain amount of time to see if there's another key of a sequence about to follow. Reducing this timeout or disabling esckeys will reduce the or eliminate the wait time.
10ix<ESC>
vs
10ix<CTRL-C>
^C cancels the current command, where ESC exits insert mode.
vs
10ix<CTRL-C>
^C cancels the current command, where ESC exits insert mode.
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).
The combination of 'jk' to <ESC> seems to be a very common solution. I use 'jj' to <ESC> myself.
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.
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. :)