Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sluggish 'c' command Visual mode #11

Closed
jwmann opened this issue Dec 20, 2013 · 7 comments
Closed

Sluggish 'c' command Visual mode #11

jwmann opened this issue Dec 20, 2013 · 7 comments

Comments

@jwmann
Copy link

jwmann commented Dec 20, 2013

When performing and command such as viwc there is almost a full second delay.

:vmap c

outputs:

v  cx                     <Plug>Exchange

I'm not sure what else to do to troubleshoot this sluggishness.
Perhaps you know more?

@wellle
Copy link
Contributor

wellle commented Dec 20, 2013

That's because vim knows about the visual mapping cx. When you press c in visual mode, Vim gives you a second to complete the cx mapping by pressing x. Only when you don't do that, it falls back to changing the visual selection.

Not sure how that could be improved though. But it bothers me too.

@jwmann
Copy link
Author

jwmann commented Dec 20, 2013

Oh, now I understand.
Wow that's quite the dilemma.

Personally, I would rather not have cx in visual mode and instead have a command like :Exchange that can be called via <leader>cx

I think that would adequately fix the issue.

@tommcdo
Copy link
Owner

tommcdo commented Dec 20, 2013

Vim uses a setting, 'timeoutlen', that determines how long it waits before using a command that's a prefix of another (like using c instead of cx). As a temporary solution, you can shorten this value to something that's long enough that you have time to type cx but short enough that when you want c, it's not unbearable.

But I admit, that's not a great solution. I like your idea of having the command that can be used for visual mode.

I had been planning to make the mappings more customizable. In doing so, I will see about making a command version for visual mode that can be used if you choose to disable the visual mapping.

tommcdo added a commit that referenced this issue Dec 22, 2013
@tommcdo
Copy link
Owner

tommcdo commented Dec 22, 2013

I've added the ability to override the default mappings (described in the :help). This can be a decent workaround for now:

vmap <Leader>cx <Plug>Exchange

I am also working on implementing the command version of these actions. I haven't found a perfect way to make the same command work nicely for both normal and visual mode (I'd prefer not to have two separate commands for it), but when I get it right I'll push up those changes. Hopefully this works well for you in the meantime.

@jwmann
Copy link
Author

jwmann commented Dec 22, 2013

@tommcdo

Thank you so much! Sounds great! :)

@michamos
Copy link
Contributor

Why not simply drop the c in visual mode? if I am not mistaken, in visual mode, both d and x delete the selection. By mapping x we still have d for delete (which is the most natural one for this function anyway IMHO).

@tommcdo
Copy link
Owner

tommcdo commented Dec 27, 2013

@michamos, to be honest I'd prefer a mapping that makes an existing command sluggish over one that replaces another existing command entirely (even if there's a suitable alternative). I'm open to recommending this as an alternative in the help, perhaps, but I don't like it as a default. Ideally, I'd find another mapping that can be consistent across all modes without causing any pain. Sadly, I can't think of a nice one right now, particularly with the same finesse (and relatively strong mnemonic quality) that cx has.

Anyway, when using the c operator from visual mode, if you do carry on typing anything that doesn't begin with x, you don't have wait for the timeout. For example, visually changing hello to goodbye could be done with viwcgoodbye without pausing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants