doc/rules-format.txt

   1 The rules file
   2 ==============
   3
   4 The purpose of the rules file is to map between configuration values
   5 that are easy for a user to specify and understand, and the
   6 configuration values xkbcomp uses and understands.
   7
   8 xkbcomp uses the xkb_component_names struct, which maps directly to
   9 include statements of the appropriate sections, called for short
  10 KcCGST (see doc/keymap-format-text-v1.txt; 'G' stands for "geometry",
  11 which is not supported). These are not really intuitive or straight-
  12 forward for the uninitiated.
  13
  14 Instead, the user passes in a xkb_rule_names struct, which consists
  15 of the name of a rules file (in Linux this is usually "evdev"), a
  16 keyboard model (e.g. "pc105"), a set of layouts (which will end up
  17 in different groups, e.g. "us,fr"), variants (used to alter/augment
  18 the respective layout, e.g. "intl,dvorak"), and a set of options
  19 (used to tweak some general behavior of the keyboard, e.g.
  20 "ctrl:nocaps,compose:menu" to make the Caps Lock key act like Ctrl
  21 and the Menu key like Compose). We call these RMLVO.
  22
  23 Format of the file
  24 ------------------
  25 The file consists of rule sets, each consisting of rules (one per
  26 line), which match the MLVO values on the left hand side, and, if
  27 the values match to the values the user passed in, results in the
  28 values on the right hand side being added to the resulting KcCGST.
  29 Since some values are related and repeated often, it is possible
  30 to group them together and refer to them by a group name in the
  31 rules.
  32
  33 Along with matching values by simple string equality, and for
  34 membership in a group defined previously, rules may also contain
  35 "wildcard" values - "*" - which always match. These usually appear
  36 near the end.
  37
  38 Grammar
  39 -------
  40 (It might be helpful to look at a file like rules/evdev along with
  41 this grammer. Comments, whitespace, etc. are not shown.)
  42
  43 File         ::= { "!" (Group | RuleSet) }
  44
  45 Group        ::= GroupName "=" { GroupElement } "\n"
  46 GroupName    ::= "$"<ident>
  47 GroupElement ::= <ident>
  48
  49 RuleSet      ::= Mapping { Rule }
  50
  51 Mapping      ::= { Mlvo } "=" { Kccgst } "\n"
  52 Mlvo         ::= "model" | "option" | ("layout" | "variant") [ Index ]
  53 Index        ::= "[" 1..XKB_NUM_GROUPS "]"
  54 Kccgst       ::= "keycodes" | "symbols" | "types" | "compat" | "geometry"
  55
  56 Rule         ::= { MlvoValue } "=" { KccgstValue } "\n"
  57 MlvoValue    ::= "*" | GroupName | <ident>
  58 KccgstValue  ::= <ident>
  59
  60 Notes:
  61
  62 - The order of values in a Rule must be the same as the Mapping it
  63   follows. The mapping line determines the meaning of the values in
  64   the rules which follow in the RuleSet.
  65
  66 - If a Rule is matched, %-expansion is performed on the KccgstValue,
  67   as follows:
  68
  69   %m, %l, %v:
  70      The model, layout or variant, if only one was given (e.g.
  71      %l for "us,il" is invalid).
  72
  73   %l[1], %v[1]:
  74      Layout or variant for the specified group Index, if more than
  75      one was given (e.g. %l[1] for "us" is invalid).
  76
  77   %+m, %+l, %+v, %+l[1], %+v[1]
  78      As above, but prefixed with '+'. Similarly, '|', '-', '_' may be
  79      used instead of '+'.
  80
  81   %(m), %(l), %(l[1]), %(v), %(v[1]):
  82      As above, but prefixed by '(' and suffixed by ')'.
  83
  84   In case the expansion is invalid, as described above, it is
  85   skipped (the rest of the string is still processed); this includes
  86   the prefix and suffix (that's why you shouldn't use e.g. "(%v[1])").