Re: xemacs and xmodmap

[email protected] wrote:

> my xemacs is just too intelligent ;)
> I set up my .Xmodmap so that "Caps Lock" ( the most senseless key on the 
> board ) creates "mod4". This way I can controll my all of my fvwm2 
> functions with this key and don't mess up other key sequences. I think 
> this makes sense, but xemacs disagrees:
> 
> (1) (key-mapping/warning) 
>         The meanings of the modifier bits Mod1 through Mod5 are determined
>         by the keysyms used to control those bits.  Mod1 does NOT always
>         mean Meta, although some non-ICCCM-compliant programs assume that.
> 
> (2) (key-mapping/warning) 
>         The semantics of the modifier bits ModShift, ModLock, and 
> ModControl
>         are predefined.  It does not make sense to assign ModControl to 
> any
>         keysym other than Control_L or Control_R, or to assign any 
> modifier
>         bits to the "control" keysyms other than ModControl.  You can't
>         turn a "control" key into a "meta" key (or vice versa) by simply
>         assigning the key a different modifier bit.  You must also make 
> that
>         key generate an appropriate keysym (Control_L, Meta_L, etc).
> 
> (3) (key-mapping/warning) XEmacs:  Caps_Lock (0x42) generates Mod4, which 
> is nonsensical.
> 
> How can i get rid of these warnings ?

Re-bind the Caps Lock key to a keysym which makes sense as a modifier,
e.g. Super_L or Hyper_L.

The way in which applications (and toolkits) are *supposed* to handle
modifier flags is to infer their interpretation from the keysyms to
which they are bound. E.g. if a modifier bit is bound to Meta_L and/or
Meta_R, then it is the "Meta" modifier.

As the first warning puts it:

>         The meanings of the modifier bits Mod1 through Mod5 are determined
>         by the keysyms used to control those bits.

The third warning is a specific instance of the more general rule.

And the second warning is effectively the inverse; it doesn't make any
sense to bind the Caps_Lock keysym to any modifier other than "Lock". 
Any modifier bit which is bound to Caps_Lock should be interpreted as
the "Caps Lock" modifier, but that's pre-defined to be "Lock", not
"Mod4".

Alternatively, you should be able to stop XEmacs complaining about the
misconfiguration by adding the key-mapping symbol to the
display-warning-suppressed-classes list, e.g.

	(push 'key-mapping display-warning-suppressed-classes)

-- 
Glynn Clements <[email protected]>