|
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.
|
|
|
8594adc4
|
2025-03-31T13:52:36
|
|
doc: Mention that `alternate` merge mode is not supported
|
|
|
343c49cc
|
2025-03-30T09:54:02
|
|
doc: Optional components
|
|
|
23598fa1
|
2025-03-25T22:52:06
|
|
Enable merge mode “replace” in include statements
Previously only the merge modes “override” and “augment” were available
in include statements, using the prefix ‘+’ and ‘|’ respectively. While
on one hand `replace` include statement can be used in keymap files, on
the other hand *rules* files have no way to express the *replace* mode.
This commit enables the merge mode “replace” using the prefix `^`. This
prefix was chosen due to its similarity with the `XOR` bit operator,
which convey *mutual exclusion*.
Other candidates:
- `!` conveys some kind of higher precedence, akin to CSS `!important`.
But it conflicts with the section header `!`, which is a token in the
current parser. It would require special handling, not worth it. It
also convey the meaning of negation, which is confusing.
- `&` has the advantage of not corresponding to a token in the rules
parser. `^` seems however to stand out more and it is less likely to
trigger erroneous comparison with `|` and `&` bit operators.
|
|
|
6fc6e64b
|
2025-03-26T10:35:22
|
|
rules: Added extended wild cards <none>, <some> and <any>
Added the following wild cards to the rules file syntax, in addition
to the current `*` legacy wild card:
- `<none>`: Match *empty* value.
- `<some>`: Match *non-empty* value.
- `<any>`: Match *any* (optionally empty) value. Its behavior does not
depend on the context, contrary to the legacy wild card `*`.
This will enable writing much simpler rules, see [!764] for an example
of tricky rules in the `xkeyboard-config` project, that would benefit
from the new wild cards.
[!764]: https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/merge_requests/764
The verbose wild cards are preferred to single characters:
- More intuitive: self-explanatory.
- Does not steal syntax from other token.
- Extensible syntax, should we need it.
A previous proposal used the characters (`!`, `+`, `?`) for their
similarity with the corresponding syntax of regular expressions
(negative assertion & quantifiers), in line with `*`. But `!` is not
that intuitive after all and conflict with its role as section header.
Furthermore, `+` is also used as a merge mode. Finally, nothing beats
whole short words for readability.
|
|
|
ecde6ade
|
2025-03-28T10:31:28
|
|
doc: Document floating-point parsing difference with Xorg xkbcomp
|
|
|
7697c712
|
2024-09-16T16:09:11
|
|
rules: Resolve relative include statements using XKB paths
Contrary to keymap files, the `! include` statement in rules does not
lookup include paths added to `xkb_context`. So it is not possible e.g.
to import another file in the same folder without using an absolute path.
- Added path utils: `is_absolute(path)`.
- Added XKB paths lookup to enable e.g. `! include evdev` to work.
- Added test.
|
|
|
fc664cf1
|
2023-05-13T05:30:11
|
|
Improve documentation
- Add introduction to XKB
- Embrace Doxygen features
- More cross links
|