doc/keymap-format-text-v1: update info on preserve

Signed-off-by: Ran Benita <ran234@gmail.com>
master
Ran Benita 2015-11-21 22:39:38 +02:00
parent 2cca028906
commit 8891953514
1 changed files with 16 additions and 21 deletions

View File

@ -129,29 +129,24 @@ forms:
map[Shift+Lock+LevelThree] = Level5; map[Shift+Lock+LevelThree] = Level5;
preserve[Shift+Lock+LevelThree] = Lock; preserve[Shift+Lock+LevelThree] = Lock;
When a map entry matches the active modifiers and the level it When a key type is used for keysym translation, its modifiers are
specified is chosen, then these modifiers are said to be "consumed"; said to be "consumed". For example, in a simple US keymap, the "g"
for example, in a simple US keymap where the "g" key is assigned an "g" key is assigned an ordinary ALPHABETIC key type, whose modifiers
ordinary ALPHABETIC key type, if the Lock (Caps Lock) modifier is are Shift and Lock; then for the "g" key, these two modifiers are
active and the key is pressed, then a "G" keysym is produced (as consumed by the translation. This information is relevant for
opposed to lower-case "g"). This is because the type definition has applications which further process the modifiers, since by then the
a map entry like the following: consumed modifiers have already "done their part" and should be
masked out.
map[Lock] = Level2; However, sometimes even if a modifier had already affected the key
translation through the type, it should *not* be reported as
And as such the Lock modifier is consumed. This information is
relevant for applications which further process the modifiers,
since by then the consumed modifiers have already "done their part"
and should be masked out.
However, sometimes even if a modifier is actually used to choose
the shift level (as Lock above), it should *not* be reported as
consumed, for various reasons. In this case, a preserve[] statement consumed, for various reasons. In this case, a preserve[] statement
can be used to augment the map entry. The modifiers inside the square can be used to augment the map entry. The modifiers inside the
brackets should match one of the map[] statements in the type. The square brackets should match one of the map[] statements in the type
right hand side should consists of modifiers from the left hand (if there is no matching map entry, one mapping to Level1 is
side; these modifiers are then "preserved" and not reported as implicitly added). The right hand side should consists of modifiers
consumed. from the type's modifiers; these modifiers are then "preserved" and
not reported as consumed.
The xkb_compat section The xkb_compat section