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 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.
