Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU (Bob Scheifler)
Newsgroups: comp.windows.x
Subject: Re: R4 xterm modmap strangeness
Message-ID: <9001121548.AA07755@expire.lcs.mit.edu>
Date: 12 Jan 90 15:48:02 GMT
References: <9001112348.AA17091@prometheus.think.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 63


    Meta is defined by "ANY (???) modifier bit whose corresponding keycode
    (what if there are >1?)  contains the corresponding left or right keysym
    (Meta_L or Meta_R, I guess)."

"one of whose corresponding keycodes" might be better wording.  You have
the idea.

    Isn't this extremely strange?

Which part do you find strange?

    Was it really like this in R3?

The specification was.  Dunno for sure about the implementation.

    (and where is it done in the source)?

You don't really want to know, but you can start in TMstate.c, e.g.
_XtBuildKeysymTables and ComputeLateBindings.

    Shouldn't this all be in the red book?

No, this is a prescript, not a PostScript. :-)

It is possible that we would have been better of standardizing interpretations
in the protocol (maroon book), I don't know.  The current (R4) protocol document
does have this to say:

    Switching between groups is controlled by the KEYSYM named
    MODE SWITCH, by attaching that KEYSYM to some KEYCODE and attaching that
    KEYCODE to any one of the modifiers Mod1 through Mod5.  This modifier is
    called the ``group modifier''.

and

    The KEYMASK modifier named Lock is intended to be mapped to either a CapsLock
    or a ShiftLock key, but which one is left as application-specific
    and/or user-specific.
    However, it is suggested that the determination be made according to the
    associated KEYSYM(s) of the corresponding KEYCODE.

so a mechanism for "defining" modifiers Mod1-Mod5 should be pretty clear.

    I'd expect this stuff to be defined with XLookupString.

XLookupString is a convenience routine, dealing only with Shift, Lock,
Control, and the group modifier.

    Clearly here you're saying that the keysym is not used to look up the
    modifier bits at run time.

That's not really what I was saying, I was describing a defect in xmodmap
and how to work around it.

    This jibes with the Xt doc, which says that
    Shift, Lock and Control are treated specially - they just look at the
    modifier map, not the keysym.  Why are they different?

Because they are considered standard modifiers, that exist on virtually every
keyboard (or on every keyboard virtually), and should have a standard
interpretation.  That's why they are "named" in the protocol, instead of being
"numbered".