Making Windows key meta

[Alex Viskovatoff <viskovatoff+news@imap.cc>]

Hi,

This issue has come up many times before on discussion groups, but the
specific problem I run into has not, as far as I am aware.

Because the laptop I use has a narrow space bar, it is inconvenient for me
to use the alt keys for meta, since the alt keys are awkwardly far away
from the control keys. I am running xorg-x11 6.7 (equivalent to XFree86
4.4) under Fedora Core 2 with Gnome 2.6, and that allows me to modify the
xkb options in my user settings. In the Gnome "Keyboard Preferences"
configuration, I select "Meta is mapped to the Win-keys", which makes the
options "altwin altwin:meta_win" sent to xkb. In an xterm, this makes the
Windows key act as meta. With this configuration, xev shows that pressing
the left Windows key yields "keycode 115 (keysym 0xffe7, Meta_L)", while
pressing the left alt key yields "keycode 64 (keysym 0xffe9, Alt_L)". This
is what I expect, and what I want.

In the previous version of Emacs I used, this configuration also made the
Windows key act as meta under Emacs. Now however, under this
configuration, pressing both the (left) Windows key or the alt key doesn't
do anything. (If I don't give the "altwin altwin:meta_win" option to xkb,
Emacs treats the alt key as meta.) Using "C-h k" shows what the problem
is. What it yields for "win-b" (pressing "b" while holding the Windows key
down) is "H-M-s-b is undefined". In other words, when one presses the
Windows key, in Emacs, not only the meta bit gets set, but also the hyper
and super bits.

On the other hand, if I don't give the "altwin altwin:meta_win" option to
xkb, pressing "b" with the Windows key down in Emacs makes "C-h k" yield
"H-S-b is undefined". Under this configuration, xev reports the Windows
key as "keycode 115 (keysym 0xffeb, Super_L)", while it continues to
report the left alt key as "keycode 64 (keysym 0xffe9, Alt_L)". Again, X
is behaving exactly as expected, since the default behavior for X is that
the Windows key is super.

So what Emacs does is the following. When the Windows key is mapped to
super (the default), Emacs treats it as "H-s". When the Windows key is
mapped to meta, emacs treats it as "H-M-s". So Emacs is aware of the
Windows key being remapped under X. But why, when the Windows key is
mapped to meta under X, does Emacs set the hyper and super bits, while not
just setting the meta bit, which would be the expected, "reasonable"
behavior?

A workaround would be to associate, for instance, the "backward-word"
command with the "H-M-s-b" keystroke, instead of "M-b". But that would be
highly kludgey, as well as breaking emacs when it is not run under X.

I thought that this strange behavior might be caused by one of Red Hat's
patches to Emacs, so I compiled the emacs 21.3 myself. The behavior is
exactly the same.

Does anyone know why Emacs behaves in this bizarre way? (As far as I can
tell, the entry "After upgrading to a newer version of Emacs, the Meta key
stops working" in the emacs "PROBLEMS" file does not lead one to expect
this behavior.) And does anyone know a reasonably easy way to make Emacs
behave in a straightforward way, that is, to interpret keyboard events
from X with the Windows key down as just having the meta bit set, as
opposed to having the hyper, meta, and super bits set?

Any clarification will be much appreciated.