We've discussed the basics of resource-naming
syntax. From the sample resource settings, it appears that what many
resource variables do is self-evident or nearly so. Among the less
obvious resource variables, there is one type of specification, an
event translation, that can be used with many clients and warrants
somewhat closer examination.
The operation of many clients, notably xterm, is
partly determined by default input event translations. For example,
selecting text with the first pointer button (an event) saves that
text into memory (an action).
In this case, the input "event" is
actually three separate X events:
[object*[subobject...]]*translations: #override\
[modifier]<event>: action
The first line is basically like any other resource specification
with a few exceptions. First, the final
argument is always
translations, indicating that one (or more) of the
event-action bindings associated with the
[object*[subobject...]]
are being modified.
Second, note that #override is not the
value of the resource; it is literal and
indicates that what follows should override any default translations.
In effect, #override is no more than a pointer to
the true value of the resource: a new
event-action mapping (on the following line) where the event may take
a modifier.
A not-so-obvious principle behind overriding translations is that you
only literally "override" a default
translation when the event(s) of the new translation match the
event(s) of a default translation exactly. If
the new translation does not conflict with any existing translation,
it is merely appended to the defaults.
To be specified as a resource, a translation table must be a single
string. The #override is followed by a backslash
(\) to indicate that the subsequent line should be
a continuation of the first.
In the previous basic syntax example, the
value is a single event-action mapping.
The value could also be a list of several
mappings, linked by the characters \n\ to make the
resource a continuous string.