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
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 . Otherwise, Ctrl-Tab works fine. I use it regularly without thinking about it. From my _vimrc: nmap w nmap W > 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 k). Plus it gives us far more single keystroke commands (eight per key). -- Best regards, Bill
Re: Mapping with Shift, Ctrl and Alt/Meta
Bill McCarthy wrote: On Sun 4-Feb-07 11:57am -0600, A.J.Mechelynck wrote: 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 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. :-) 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 11:57am -0600, A.J.Mechelynck wrote: > 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 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. > 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 :-) 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.] -- Best regards, Bill
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:echo "F7" map :echo "A-F7" map :echo "C-F7" map :echo "S-F7" map:echo "A-C-F7" map:echo "A-S-F7" map:echo "C-S-F7" map :echo "A-C-S-F7" The output of :map is: :echo "A-C-S-F7" :echo "C-S-F7" :echo "A-S-F7" :echo "A-C-F7" :echo "C-F7" :echo "A-F7" :echo "S-F7" :echo "F7" All 8 work fine. I tried this with special key and that also worked fine for all 8 variants. Next I tried the letter z. I used the same script as for testing but substituting f7 with z and replacing "map " with "map z". The output of :map is: :echo "C-S-z" Z:echo "S-z" z:echo "z" š:echo "A-C-S-z" Ú:echo "A-S-z" ú:echo "A-z" Only 6 maps appear. The and override each other - they are not case sensitive. No matter which way they are defined, executing the map with either or works fine. I'm comfortable with this behavior. The and 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 "," :echo "A-C-S-," :echo "C-S-," :echo "A-S-," :echo "A-C-," :echo "S-," :echo "C-," ¬:echo "A-," All 8 appear, however only 2 work. The working maps are for "," and "A-,". I expected to map the '<' key. I'm surprised that 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 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 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 is stored in the 'term' option (which cannot be changed in gvim). ":set termcap" displays the currently known terminal settings
Mapping with Shift, Ctrl and Alt/Meta
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:echo "F7" map :echo "A-F7" map :echo "C-F7" map :echo "S-F7" map:echo "A-C-F7" map:echo "A-S-F7" map:echo "C-S-F7" map :echo "A-C-S-F7" The output of :map is: :echo "A-C-S-F7" :echo "C-S-F7" :echo "A-S-F7" :echo "A-C-F7" :echo "C-F7" :echo "A-F7" :echo "S-F7" :echo "F7" All 8 work fine. I tried this with special key and that also worked fine for all 8 variants. Next I tried the letter z. I used the same script as for testing but substituting f7 with z and replacing "map " with "map z". The output of :map is: :echo "C-S-z" Z:echo "S-z" z:echo "z" š:echo "A-C-S-z" Ú:echo "A-S-z" ú:echo "A-z" Only 6 maps appear. The and override each other - they are not case sensitive. No matter which way they are defined, executing the map with either or works fine. I'm comfortable with this behavior. The and 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 "," :echo "A-C-S-," :echo "C-S-," :echo "A-S-," :echo "A-C-," :echo "S-," :echo "C-," ¬:echo "A-," All 8 appear, however only 2 work. The working maps are for "," and "A-,". I expected to map the '<' key. I'm surprised that 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 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. -- Best regards, Bill