RE: Mapping with Shift, Ctrl and Alt/Meta
Using Ctrl-V, I can see that Gvim doesn't see Alt-Ctrl or Alt-Ctrl-Shift for normal keys, just for function keys, insert/delete, home/end, page-up/down an the arrow keys. This is NOT a Windows issue. My email program (The Bat!), for example, lets me make use of all of those combinations. I believe it is a bug in the Gvim keyboard handling. The tab key is a bit of an oddity. Of the eight possibilities, Ctrl-Tab and Alt-Ctrl-Tab don't work, although Ctrl-Shift-Tab and Alt-Ctrl-Shift-Tab do work. [Windows always takes over Alt-Tab and Alt-Shift-Tab.] Actually, it *might* be a Windows issue. If you do a typical Control-Panel thing where you get a bunch of pages with the little tabs on top, regular tab will run through all the fields/buttons/etc. on that page, but ctl-tab will pop over to the next tab. Eg, just picking one at random, Control Panel -- Folder Options, cycling through the options in General is done with the tab key, but getting to the View, File Types, etc., is done via ctl-tab. (Just tried it now, I speak the trvth. :) ) I try to never ever ever use the moose unless I'm practically forced at gunpoint, well, at least if the program/app is sucky enough to not have a keyboard way to do something, so this is kind of familiar to me. Sooo, point was that it might very well he a grabbed key-combo, even if nothing's immediately done with it.
Re: Mapping with Shift, Ctrl and Alt/Meta
Bill McCarthy wrote: Hello Vim List, First I should mention that I'm using Windows and a native compiler (MinGW). Meta (M) and Alt (A) are exchangeable in Windows - I use Alt (A) below. For each function key, Vim should give me as many as 8 maps per key. All testing was done in normal mode. To check this, the following script was used: map f7 :echo F7CR map a-f7 :echo A-F7CR map c-f7 :echo C-F7CR map s-f7 :echo S-F7CR map a-c-f7 :echo A-C-F7CR map a-s-f7 :echo A-S-F7CR map c-s-f7 :echo C-S-F7CR map a-c-s-f7 :echo A-C-S-F7CR The output of :map is: M-C-S-F7 :echo A-C-S-F7CR C-S-F7 :echo C-S-F7CR M-S-F7 :echo A-S-F7CR M-C-F7 :echo A-C-F7CR C-F7 :echo C-F7CR M-F7 :echo A-F7CR S-F7 :echo S-F7CR F7 :echo F7CR All 8 work fine. I tried this with special key Home and that also worked fine for all 8 variants. Next I tried the letter z. I used the same script as for testing F7 but substituting f7 with z and replacing map f7 with map z. The output of :map is: C-Z:echo C-S-zCR Z:echo S-zCR z:echo zCR š:echo A-C-S-zCR Ú:echo A-S-zCR ú:echo A-zCR Only 6 maps appear. The C-z and C-S-z override each other - they are not case sensitive. No matter which way they are defined, executing the map with either C-z or C-Z works fine. I'm comfortable with this behavior. The A-C-z and A-C-S-z also override each other. However the most recent define does not work. It seems strange that mapping the normal keyboard cannot be done with an Alt-Ctrl. So although 6 maps appear in :map, only 5 actually work. Finally, I tried comma. The output of :map is: ,:echo ,CR C-S-¬ :echo A-C-S-,CR C-S-, :echo C-S-,CR S-¬:echo A-S-,CR C-¬:echo A-C-,CR S-,:echo S-,CR C-,:echo C-,CR ¬:echo A-,CR All 8 appear, however only 2 work. The working maps are for , and A-,. I expected S-, to map the '' key. I'm surprised that C-, doesn't work - is it that way on 'nix systems? Should Vim store the 1 non-working map for z and the 6 non-working maps for comma? Also, why doesn't A-C-key work for normal keyboard characters? Finally, why use these strange decorated characters for maps containing an Alt? These make the output of :map (and relatives) useless for those mappings. Ctrl+printable key is not portably defined for other than the following: Ctrl-? 127 0x7F Ctrl-@ 0 0x00 NUL Ctrl-A 1 0x01 also Ctrl-a Ctrl-B 2 0x02 also Ctrl-b Ctrl-C 3 0x03 also Ctrl-c Ctrl-D 4 0x04 also Ctrl-d Ctrl-E 5 0x05 also Ctrl-e Ctrl-F 6 0x06 also Ctrl-f Ctrl-G 7 0x07 BEL also Ctrl-g Ctrl-H 8 0x08 BS also Ctrl-h Ctrl-I 9 0x09 HT also Ctrl-i Ctrl-J 10 0x0A LF also Ctrl-j Ctrl-K 11 0x0B also Ctrl-k Ctrl-L 12 0x0C FF also Ctrl-l Ctrl-M 13 0x0D CR also Ctrl-m Ctrl-N 14 0x0E also Ctrl-n Ctrl-O 15 0x0F also Ctrl-o Ctrl-P 16 0x10 also Ctrl-p Ctrl-Q 17 0x11 also Ctrl-q Ctrl-R 18 0x12 also Ctrl-r Ctrl-S 19 0x13 also Ctrl-s Ctrl-T 20 0x14 also Ctrl-t Ctrl-U 21 0x15 also Ctrl-u Ctrl-V 22 0x16 also Ctrl-v Ctrl-W 23 0x17 also Ctrl-w Ctrl-X 24 0x18 also Ctrl-x Ctrl-Y 25 0x19 also Ctrl-y Ctrl-Z 26 0x1A also Ctrl-z Ctrl-[ 27 0x1B ESC Ctrl-\ 28 0x1C Ctrl-] 29 0x1D Ctrl-^ 30 0x1E Ctrl-_ 31 0x1F The above (which date back to the time of 8-bit computers, the first of which had only printable keys plus Shift and Ctrl; maybe even to the time of 7-bit teletypewriters) explain why Vim sees Tab and Ctrl-I, Enter and Ctrl-M, Esc and Ctrl-[ as pairs of synonyms. Alt+printable key is usually translated by (key OR 0x80). Also Alt+ control keys above. This explains your decorated characters: for instance, since z is 0x7A, Alt-z is mapped as 0xFA which (in Latin1 encoding) is ú (small u with acute accent). Similarly, Alt-space should map to 0xA0, the non-breaking space character known to HTML writers as nbsp; This also means that Alt+printable key should not be used for Insert-mode mappings because they collide with accented characters which one may want to be able to input directly. Non-printable keys generate (with a few exceptions like Esc, Tab and Enter) more than one byte of keyboard data; and Alt and/or Ctrl and/or Shift combinations (with non-printable keys) are mapped separately. The translations (which vary between terminal models) rely on the termcap/terminfo libraries (see :help startup-terminal). For instance, gvim uses builtin_gui, a builtin entry (precompiled into gvim), and console Vim may use linux, xterm, vt100 (which are common on Unix/Linux systems), pcterm, win32 (which are common on Dos/Windows systems) or something else depending on the particular console terminal it is using. The current terminal type
Re: Mapping with Shift, Ctrl and Alt/Meta
Bill McCarthy wrote:
On Sun 4-Feb-07 11:57am -0600, A.J.Mechelynck wrote:
snip
Alt+printable key is usually translated by (key OR 0x80).
Also Alt+ control keys above. This explains your
decorated characters: for instance, since z is 0x7A,
Alt-z is mapped as 0xFA which (in Latin1 encoding) is ú
(small u with acute accent). Similarly, Alt-space should
map to 0xA0, the non-breaking space character known to
HTML writers as nbsp; This also means that Alt+printable
key should not be used for Insert-mode mappings because
they collide with accented characters which one may want
to be able to input directly.
Thanks for all that info on non-printables. It is now easy
to figure out the Alt-x combos.
My pleasure. :-)
snip
Depending on the underlying OS and window manager, some key combinations can
be preempted by the window manager, and never reach Vim. For instance, on my
Linux system with kwm window manager, Alt-Fn triggers a system menu or action,
Ctrl-Alt-Fn selects a virtual console ({1..12} are defined and {1..7,10} are
actually used) and Ctrl-Fn selects a virtual desktop (the number of such
virtual desktops is user-defined; I have 20 so all 12 Ctrl-Fn keys are taken).
Thus I can use Fn and Shift-Fn in gvim but not Ctrl-Fn, Alt-Fn or Ctrl-Alt-Fn
because the latter three kinds never reach any program running in X11.
I'm sure glad I don't have X11 to deal with :-)
It's the kind of thing one has to take into account when writing a vimrc for a
dual-boot system, or a public script which could be used on any (g)vim
installation. X11 has other advantages over Windows: I've used them both and
I'm not going back.
Using Ctrl-V, I can see that Gvim doesn't see Alt-Ctrl or
Alt-Ctrl-Shift for normal keys, just for function keys,
insert/delete, home/end, page-up/down an the arrow keys.
This is NOT a Windows issue. My email program (The Bat!),
for example, lets me make use of all of those combinations.
I believe it is a bug in the Gvim keyboard handling.
The tab key is a bit of an oddity. Of the eight
possibilities, Ctrl-Tab and Alt-Ctrl-Tab don't work,
although Ctrl-Shift-Tab and Alt-Ctrl-Shift-Tab do work.
[Windows always takes over Alt-Tab and Alt-Shift-Tab.]
I can't test Ctrl-Tab here because it's one of those keys which are preempted
by the window manager (Ctrl-Tab and Ctrl-Shift-Tab cycle through virtual
desktops the way Alt-Tab and Alt-Shift-Tab cycle through the open windows of
the current desktop). Doesn't Vim see it as synonymous with Tab?
Shift-Tab is a meaningful key (tab backwards) which is handled like
non-printable keys (multibyte keyboard sequence dependent on the terminal).
Vim can map such combos provided that it can see them.
I don't know how TheBat! gets its special-key keyboard input (raw or cooked
for instance). IIUC, Vim uses cooked keyboard input, which is more portable
across platforms and keyboard layouts, but is less powerful for complex key
combinations since there is an additional software layer between the keyboard
hardware and the program -- and that can conceivably lead to loss of
information if the user presses a key combo not foreseen (or discarded as not
meaningful) by the translation software. Rather than a bug, I would call it
a limitation of the way Vim gets its keyboard input.
Best regards,
Tony.
Re: Mapping with Shift, Ctrl and Alt/Meta
On Sun 4-Feb-07 3:39pm -0600, A.J.Mechelynck wrote: I can't test Ctrl-Tab here because it's one of those keys which are preempted by the window manager (Ctrl-Tab and Ctrl-Shift-Tab cycle through virtual desktops the way Alt-Tab and Alt-Shift-Tab cycle through the open windows of the current desktop). Doesn't Vim see it as synonymous with Tab? Shift-Tab is a meaningful key (tab backwards) which is handled like non-printable keys (multibyte keyboard sequence dependent on the terminal). Vim can map such combos provided that it can see them. Yes, in the Ctrl-V context, Ctrl-Tab behaves like Tab. Ctrl-Shift-Tab, after Ctrl-V produces C-S-Tab. Otherwise, Ctrl-Tab works fine. I use it regularly without thinking about it. From my _vimrc: nmap silent C-Tab C-Ww nmap silent S-Tab C-WW I don't know how TheBat! gets its special-key keyboard input (raw or cooked for instance). IIUC, Vim uses cooked keyboard input, which is more portable across platforms and keyboard layouts, but is less powerful for complex key combinations since there is an additional software layer between the keyboard hardware and the program -- and that can conceivably lead to loss of information if the user presses a key combo not foreseen (or discarded as not meaningful) by the translation software. Rather than a bug, I would call it a limitation of the way Vim gets its keyboard input. I agree that its more of a limitation than a bug. It's too bad - I start Gvim with go=M so I see no GUI stuff and work with just the keyboard. I find it easier to press a modified keystroke (like Alt-Ctrl-k or Ctrl-Shift-k) then multiple keystrokes (like leaderk). Plus it gives us far more single keystroke commands (eight per key). -- Best regards, Bill
