I have made a mapping xnoremap j; <Esc> where j; puts you into normal mode if you're in visual mode. Having this mapping in my vimrc slows down visual selection. I can't figure out why this is the case.

Example: If you select a line in visual selection mode and move a line down you have to wait a few seconds before the selection updates.

  • 1
    This isn't directly related to your question, but why would have xnoremap j; <Esc>? Isn't j; more work than typing <esc>? How does that save you time/effort? – DJMcMayhem Feb 1 at 19:18
  • I chose for j; because this way you don't have to take your fingers of the home row keys like you would have to if you were using <esc>. Having said that I've switched to using the capslock key with the help of an autohotkey script. This is the best of both worlds I feel. Lesser keystrokes than j; and closer to the home row than <esc>. – BvdL Feb 1 at 19:35

Well, whenever you hit j vim has to wait. Is it a "real" j and the user wants to move down, or is he/she entering an additional ; to trigger the mapping j;?

I guess you should chose another mapping.

  • Thanks for the help, you're right. I didn't take the waiting into account when making the mapping. – BvdL Feb 1 at 11:02
  • That's the easiest 135 points I've ever seen anyone earn on this site. ;) – B Layer Feb 18 at 10:25
  • 1
    @BLayer :-) Lucky one. I agree I should have mentioned timeoutlen. – Ralf Feb 18 at 10:49
  • More power to you! (Thanks for the vote....if that was you.) – B Layer Feb 18 at 11:01

Even though the accepted answer is correct and OP has moved away from using a mapping that is subject to the root cause I feel like an important detail has been omitted.

The time that Vim waits to see if the next keystroke is part of a mapped key sequence or not is configurable via the 'timeoutlen' (abbreviation 'tm') setting. It contains the delay in milliseconds and the default is 1000 which is a quite conspicuous wait for an interactive application.

If you were particularly set on using a mapping that is subject to the kind of issues described by OP then you can set it to something like 100. I find 100 to be plenty enough time to enter in a pair of characters while at the same time not being too disruptive to my flow in those cases where it's applicable. If you're really quick you can even set it to 0.

(I don't know what the actual delay is in the case of 0. It's not literally 0 or it wouldn't work. I should look at the code but I suppose it could mean a "natural" delay, i.e. there's always some fudge factor to timings in non-real-time systems. Maybe thanks the buffering characteristics vim pulls more than one input char in a loop iteration so the timer doesn't get incremented. Or a millisecond granularity clock is being used and the char fetch loop is executed multiple times before it is incremented. Or....ah never mind. It's quick!)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.