Mixing
Why does xnoremap mapping make visual selection slow?
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.
vimrc key-bindings
asked Feb 1 at 10:40
BvdLBvdL
336
add a comment |
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.
vimrc key-bindings
asked Feb 1 at 10:40
BvdLBvdL
336
1
This isn't directly related to your question, but why would havexnoremap j; <Esc>? Isn'tj;more work than typing<esc>? How does that save you time/effort?
– DJMcMayhem♦
Feb 1 at 19:18
I chose forj;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>.
– BvdL
Feb 1 at 19:35
add a comment |
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.
vimrc key-bindings
asked Feb 1 at 10:40
BvdLBvdL
336
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.
vimrc key-bindings
vimrc key-bindings
asked Feb 1 at 10:40
BvdLBvdL
336
asked Feb 1 at 10:40
BvdLBvdL
336
asked Feb 1 at 10:40
BvdLBvdL
336
asked Feb 1 at 10:40
BvdLBvdL
336
asked Feb 1 at 10:40
BvdLBvdL
336
336
1
This isn't directly related to your question, but why would havexnoremap j; <Esc>? Isn'tj;more work than typing<esc>? How does that save you time/effort?
– DJMcMayhem♦
Feb 1 at 19:18
I chose forj;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>.
– BvdL
Feb 1 at 19:35
add a comment |
1
This isn't directly related to your question, but why would havexnoremap j; <Esc>? Isn'tj;more work than typing<esc>? How does that save you time/effort?
– DJMcMayhem♦
Feb 1 at 19:18
I chose forj;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>.
– BvdL
Feb 1 at 19:35
1
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
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
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
add a comment |
2 Answers
2
active
oldest
votes
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.
answered Feb 1 at 10:45
RalfRalf
3,4251317
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 mentionedtimeoutlen.
– 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
add a comment |
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!)
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "599"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fvi.stackexchange.com%2fquestions%2f18761%2fwhy-does-xnoremap-mapping-make-visual-selection-slow%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Feb 1 at 10:45
RalfRalf
3,4251317
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 mentionedtimeoutlen.
– 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
add a comment |
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.
answered Feb 1 at 10:45
RalfRalf
3,4251317
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 mentionedtimeoutlen.
– 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
add a comment |
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.
answered Feb 1 at 10:45
RalfRalf
3,4251317
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.
answered Feb 1 at 10:45
RalfRalf
3,4251317
answered Feb 1 at 10:45
RalfRalf
3,4251317
answered Feb 1 at 10:45
RalfRalf
3,4251317
answered Feb 1 at 10:45
RalfRalf
3,4251317
3,4251317
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 mentionedtimeoutlen.
– 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
add a comment |
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 mentionedtimeoutlen.
– 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
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
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
That's the easiest 135 points I've ever seen anyone earn on this site. ;)
– B Layer
Feb 18 at 10:25
1
1
@BLayer :-) Lucky one. I agree I should have mentioned
timeoutlen.– Ralf
Feb 18 at 10:49
@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
More power to you! (Thanks for the vote....if that was you.)
– B Layer
Feb 18 at 11:01
add a comment |
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!)
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
add a comment |
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!)
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
add a comment |
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!)
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
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!)
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
edited Feb 18 at 11:19
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
answered Feb 18 at 10:12
B LayerB Layer
5,9521418
5,9521418
add a comment |
add a comment |
Thanks for contributing an answer to Vi and Vim Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fvi.stackexchange.com%2fquestions%2f18761%2fwhy-does-xnoremap-mapping-make-visual-selection-slow%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
This isn't directly related to your question, but why would have
xnoremap j; <Esc>? Isn'tj;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 thanj;and closer to the home row than<esc>.– BvdL
Feb 1 at 19:35