Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph Swick)
Newsgroups: comp.windows.x
Subject: Re: Problem with multi-key translations in Xt Intrinsics.
Message-ID: <9008160246.AA03209@lyre.MIT.EDU>
Date: 16 Aug 90 02:46:11 GMT
References: <1990Aug13.152553.114@unx.sas.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 37


    The behavior is that non-initial key events associated
    with a multi-key event sequence are thrown away even though a translation
    action exists in the table that should receive the event.

This is an interesting case of ambiguity in the Xt specification.
To summarize, given the translation specification

  <Key>a,<Key>b	: something()
  <Key>		: else()

then <KeyPress>b events not preceeded by <KeyPress>a wind up
being discarded as a side-effect of the rule that "more specific
events must preceed more general events".  I won't argue with
anyone claiming that this is non-intuitive.  You'd probably
argue (and in theory, I'd probably agree) that 'a' is meant to
be a prefix character ala emacs and that un-prefixed 'b' should
invoke the else() action.  You'd still have to invoke the "more
specific preceed more general" rule to explain why 'a' not
followed by 'b' should go into the bit-bucket, if that's what
you want to have happen.

Such a rule is easy to implement (it's 1 line; I just did it)
but it opens a big compatibility can o'worms.  If it were to
become part of the implementation, we'd have to provide
a compatibility mode for the current behavior.

Fortunately, there's a simple alternative: you can specify

  <Key>a,<Key>b	: something()
  <Key>b	: else()
  <Key>		: else()

to get the behavior in the preceeding paragraph.  Yes, it's
ugly, but it may be the best option available.

-Ralph