kc3-lang/libxkbcommon /doc/compatibility.md

Branch :

Log

Author	Commit	Date	CI	Message
	66f71890	2025-03-31 08: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-31 13:52:36		doc: Mention that `alternate` merge mode is not supported
	343c49cc	2025-03-30 09:54:02		doc: Optional components
	23598fa1	2025-03-25 22: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-26 10: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-28 10:31:28		doc: Document floating-point parsing difference with Xorg xkbcomp
	7697c712	2024-09-16 16: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-13 05:30:11		Improve documentation - Add introduction to XKB - Embrace Doxygen features - More cross links