doc/keymap-format-text-v1: update info on preserve
Signed-off-by: Ran Benita <ran234@gmail.com>master
parent
2cca028906
commit
8891953514
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue