Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My understanding is that Vim cannot differentiate between <c-s-[key]> and <c-[key]> because they map to the same ascii code. And also the same reason why <c-i> is equivalent to <tab>. Similarly, you can't map <c-1>, <c-;>, etc. because there is no ascii representation.

I've read some people say this restriction is fine since it's more ergonomic to avoid chords/modifiers in favour of words anyway (eg. with leader key). But some operations are just more appropriate for chords/modifiers (like things that you're likely to repeat with)

What I'm asking is why was Vim designed like this in the first place? Or why, since Vim is open source, there is no build of Vim or GVim that has added support for this? It seems a shame for an editor that is so ridiculously customizable to limit itself this way. Can anyone explain this to me?

share|improve this question
    
For anyone interested in workarounds, I've been able to get away with using autohotkey for this. Vim does recognize <c-f1> to <c-f12> and <s-f1> to <s-f12> so you can get autohotkey to map any c-s-[key] combination to one of those (for vim only), then map one of those to whatever you want in vim –  eventualEntropy Apr 10 '13 at 3:21

3 Answers 3

up vote 1 down vote accepted

Due to the way that the keyboard input is handled internally, this unfortunately isn't generally possible today, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or command-line mode, try typing the key combination. If nothing happens / is inserted, you cannot use that key combination. This also applies to <Tab> / <C-I>, <CR> / <C-M> / <Esc> / <C-[> etc. (Only exception is <BS> / <C-H>.) This is a known pain point, and the subject of various discussions on vim_dev and the #vim IRC channel.

Some people (foremost Paul LeoNerd Evans) want to fix that (even for console Vim in terminals that support this), and have floated various proposals, cp. http://groups.google.com/group/vim_dev/browse_thread/thread/626e83fa4588b32a/bfbcb22f37a8a1f8

Essentially, Vim would have to use more modern libraries that support modern terminal emulator capabilities to retrieve the raw key codes. The challenge is that these key codes are (mis-)used in a lot of places in the Vim source code, and updating such a central structure is difficult.

But as of today, no patches or volunteers have yet come forward, though many have expressed a desire to have this in a future Vim 8 major release. If you think this is a pain point and are able to contribute, the vim_dev mailing list mailing list is the place to volunteer.

share|improve this answer

Vim does allow <C- and <C-S- modifiers on the arrow keys because these combinations are handled by some terminal emulators, but I think that's all. It generally limits itself to key codes that can be generated by terminal emulators.

Vim was designed like this in the first place because it is Vi-IMproved and vi was designed to be used with the CRT terminals of the time, which sent and received ASCII characters. Since then, Vim has evolved according to the principles discussed in

:help design-goals

Particularly relevant are these items:

  • Minimize using CTRL and other modifiers, they are more difficult to type.
  • People switch from one platform to another, and from GUI to terminal version. Features should be present in all versions, or at least in as many as possible with a reasonable effort. Try to avoid that users must switch between platforms to accomplish their work efficiently.
  • Vim is not a fancy GUI editor that tries to look nice at the cost of being less consistent over all platforms. But functional GUI features are welcomed.

So, any key codes that are available only from a GUI and not a terminal emulator are generally avoided so that anything that can be done in gvim can be done in vim. This is considered by most users of Vim to be a feature.

share|improve this answer

The vim-dev mailing list is probably a better place for this question.

Could you elaborate on this part: "like things that you're likely to repeat with"?

Anyway, a vim that does what you want doesn't exist because not enough users care about that. Chords are both an ergonomic nightmare and a result of the limitations of modeless editing. When you remove all the OS-level shortcuts, there are simply not enough available keys for your mappings which forces you in turn to construct elaborate and unpractical chords. <C-S-w> is not better than ,w by any stretch of the imagination.

Vim's approach, with key sequences like ,bc or whatever you want, is a lot more scalable and a lot gentler with your body.

share|improve this answer
    
Some things, like a mapping for :tabnext / :tabprev, are often done multiple times consecutively (and also don't work with the repeat operator). Or swapping current window with another one. Or moving forward by camel case word. I'd argue that c-s-w is better than ,w in these cases once you start doing them multiple times in sequence. –  eventualEntropy Apr 10 '13 at 3:19
    
. repeats changes, no wonder it doesn't work with :tabnext/:tabprev. Considering that using lots of tabs is largely a mistake in Vim, gt/gT are more than sufficient, IMO. Less "familiar" than the complex and unintuitive shortcuts used by most other editors, maybe, but largely as effective if not more. But we don't agree on that, apparently. Anyway, if you feel like forking Vim… by all means go ahead! –  romainl Apr 10 '13 at 5:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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