In a terminal, one cannot distinguish Ctrl+A and Ctrl+Shift+A as they both emit the same key code, so I can see why Vi
If what bothers you is loosing existing C-V functionality, you can use C-Q instead. See, :help CTRL-V-alternative.
Gvim doesn't do it because vim cannot do it (under normal circumstances). Sorry, but that's just how it is.
However...
Some terminals (e.g., xterm and iterm2) can be configured to send an arbitrary escape sequence for any combination of keys.
For example, add the following to .Xresources
for xterm to send <Esc>[65;5u
for CtrlShiftA. You can then map that in Vim to <C-S-a>
. (65 is the decimal Unicode value for shift-a and 5 is the bit for the ctrl modifier. The u in this case stands for "unicode".)
! .Xresources
XTerm*vt100.translations: #override Ctrl ~Meta Shift <Key>a: string(0x1b) string("[65;5u")
iTerm and [u]rxvt can also be configured to do this (examples not provided).
More info: http://www.leonerd.org.uk/hacks/fixterms/
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
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 release.
As already pointed out, there are no ways to map <C-S-A>
differently from <C-A>
.
However, using tools like autokey (for linux & windows) or autohotkey (for windows), you can remap <C-S-A>
to send a different key-stroke(s) for specific applications.
e.g. On my system, I have this setting in autokey
:
$ cat ~/.config/autokey/data/gnome-terminal/ctrlshifta-gnome-terminal.py
#ctrl+shift+a sends '<S-F1>a'
keyboard.send_keys("<shift>+<f1>a") # Note that `f` in `f1` needs to be in lower case.
Assign it these properties:
ctrl+shift+a
gnome-terminal-server.Gnome-terminal
Then your ~/.vimrc
can create mapping for <S-F1>a
to do whatever you want.
Notes:
<S-F1>
as kind of leader key for detecting <C-S>
. This was because my terminal did not accept <F13>
-<F37>
etc keys. If your application supports it, (gvim
does I think) using those keys is recommended.vim
in gnome-terminal
. So I used window class = gnome-terminal-server.Gnome-terminal
as filter. Modify it to use gvim
if you want. autokey
supports a button for capturing any other window's properties like class/title.NeoVim now offers this functionality for both its terminal and gui clients. See :h nvim-features-new
As you've noted, you get the same keycode. So the only way to distinguish them is to check the state of the Shift key in your event handling function. Of course, if you have more than 0.5 second delay between keypress and processing, you'll miss some hits.