Re: key-mapping/warning

Gilles-Claude Rajaobelina wrote:

> what are the (simple) steps to get rid of following warnig at every
> xemacs invocation ?

> (3) (key-mapping/warning) XEmacs:  Mod1 is being used for both
> Mode_switch and Meta.

	xmodmap -e 'remove Mod1 = Mode_switch'

Or maybe:

	xmodmap -e 'keysym Mode_switch = Meta_R'

The first will typically disable the AltGr key (the one immediately to
the right of the space bar), while the second will make it behave the
same as the Alt key (the one immediately to the left of the space
bar).

Those commands will last for the duration of the X session. To make
permanent changes, place the actual command (without the "xmodmap -e"
or the single quotes) into your ~/.Xmodmap file.

I say "typically", because the relationship between physical keys
(e.g. Alt and AltGr) and keysyms (e.g. Mode_switch and Meta_R) is
configurable. You can use the "xev" program to figure out which keys
produce which keysyms.

The essential point of the warning is that XEmacs can't figure out
what the Mod1 bit "means", i.e. what it should do if it receives a key
event for which the Mod1 bit is set.

In order to determine the meaning of a modifier bit, it must be bound
either to a single keysym, or to a "matched" pair of keysyms (e.g. 
Meta_L and Meta_R).

[The following paragraph isn't relevant in your specific case, but it
may be useful to anyone with a similar problem who finds this message
in an archive.]

Furthermore, certain modifiers (but not Mod1 through Mod5) have a
specific meaning, and must only be bound to the "correct" keys (e.g. 
the Control modifier must only be bound to Control_L and/or
Control_R), otherwise it will create ambiguity.

Additional information can be found in the xmodmap manpage.

[On recent versions of X11, the XKEYBOARD extension (also known as
Xkb) has an effect on the situation. However, it's entirely possible
(and a lot easier, in light of the complexity of Xkb and a lack of
useful Xkb documentation) to just ignore Xkb and fix any issues using
xmodmap.]

-- 
Glynn Clements <[email protected]>