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!)
xnoremap j; <Esc>
? Isn'tj;
more work than typing<esc>
? How does that save you time/effort?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 thanj;
and closer to the home row than<esc>
.