|
181bc9ec
|
2025-09-24T20:10:00
|
|
xkbcomp: Fix numeric keysym parsing
Keysyms written as single decimal digits are interpreted in the range
`XKB_KEY_0`..`XKB_KEY_9`, consistent with the general interpretation
`<name>` -> `XKB_KEY_<name>`, e.g.:
- `1` → `XKB_KEY_1`
- `a` → `XKB_KEY_a`
However, before this commit integers in the range 0..9 in *any format*
were treated as digit keysyms, which is wrong if the number is written
with 2+ characters. E.g. the following were wrongly treated as the
keysym digit `XKB_KEY_1`: `01`, `0x1`.
Fixed by introducing a new token type to handle this corner case.
This is a preparatory work to enable serializing keysyms as numbers.
|
|
|
d5b779e1
|
2025-05-06T21:07:28
|
|
keymap: Fix empty compat interpretation map serialization
X11’s `xkbcomp` requires at least one compat interpretation entry.
|
|
|
66f71890
|
2025-03-31T08:01:29
|
|
symbols: Enable writing keysyms list as UTF-8 strings
Each Unicode code point of the string will be translated to their
respective keysym, if possible. An empty string denotes `NoSymbol`.
When such conversion is not possible, this will raise a syntax error.
This introduces the following syntax:
```c
// Empty string = `NoSymbol`
key <1> {[""]}; // NoSymbol
// Single code point = single keysym
key <2> {["é"]}; // eacute
// String = translate each code point to their respective keysym
key <3> {["sßξك🎺"]}; // {s, ssharp, Greek_xi, Arabic_kaf, U1F3BA}
// Mix string and keysyms
key <4> {[{"ξ", Greek_kappa, "β"}]}; // { Greek_xi, Greek_kappa, Greek_beta}
```
It can also be used wherever a keysym is required, e.g. in `interpret`
and `modifier_map` statements. In these cases a single keysym is expected,
so the string should contain *exactly one* Unicode code point.
|
|
|
8ba5c453
|
2025-03-30T10:07:10
|
|
xkbcomp: Use section reference as default section name
Before this commit the following keymap:
```c
xkb_keymap {
xkb_keycode {};
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" {};
};
```
This is both useless and wasting allocation: section names are optional,
so we should just remove this default name altogether and keep it
undefined, as in the original keymap.
The situation is a bit different if there is an include, as for keymaps
created from RMLVO names. Before this commit, the following keymap:
```c
xkb_keymap {
xkb_keycode { include "evdev+aliases(qwerty)" };
};
```
would result in (boilerplate removed):
```c
xkb_keymap {
xkb_keycode "(unnamed)" { … };
};
```
With this commit we now follow the Xorg xkbcomp style by using the
section reference (the include string) as the *default* section name. So
the previous example would now result in:
```c
xkb_keymap {
xkb_keycode "evdev_aliases(qwerty)" { … };
};
```
which is useful to give a hint of the original include.
Note that if the original section had a name, it would preserve it:
```c
xkb_keymap {
xkb_keycode "test" { include "evdev+aliases(qwerty)" };
};
```
would compile to:
```c
xkb_keymap {
xkb_keycode "test" { … };
};
```
|
|
|
e5401b07
|
2025-03-26T16:02:58
|
|
symbols: Improve Modmap parsing
Parse, dont’t validate: ensure *at parsing* that `modifier_map`
definitions use a list of keys and keysyms.
This enables to remove the redundant `ExprResolveKeySym` and have keysym
parsing exclusively in handled in `parser.y`.
|