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
    Commented Feb 1, 2019 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>.
    – bas
    Commented Feb 1, 2019 at 19:35

2 Answers 2


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.
    – bas
    Commented Feb 1, 2019 at 11:02
  • That's the easiest 135 points I've ever seen anyone earn on this site. ;)
    – B Layer
    Commented Feb 18, 2019 at 10:25
  • 1
    @BLayer :-) Lucky one. I agree I should have mentioned timeoutlen.
    – Ralf
    Commented Feb 18, 2019 at 10:49
  • More power to you! (Thanks for the vote....if that was you.)
    – B Layer
    Commented Feb 18, 2019 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 and acknowledge you have read our privacy policy.

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