Drafted by ChatGPT
Problem
Some generated entries contain a UTF-8 result string followed by multiple result keysyms:
<Multi_key> ... : "🆑︎" U1F191 UFE0E
The Xlib Compose grammar permits only:
"STRING"
keysym
"STRING" keysym
libxkbcommon uses the same model: one optional UTF-8 string and one optional keysym. Extra result keysyms are therefore invalid. Multi-codepoint output should be kept entirely in the string:
This occurs in both Compose and Logograms.
Reproduction
xkbcli compile-compose --verbose --test Compose
Errors include:
xkbcommon: ERROR: [XKB-685] ... unrecognized modifier "UFE0E"
xkbcommon: ERROR: [XKB-685] Logograms:604:63: unrecognized modifier "U122E9"
xkbcommon: ERROR: ... too many errors
xkbcommon: ERROR: ... failed to parse file
This prevents Fcitx5 from loading the Compose table. Removing the extra result keysyms from both files fixes it.
Why it may appear to work with Xlib
libX11’s parser also accepts at most one result keysym. On a malformed line, however, it skips to the end of that line and continues parsing, so the collection may appear to work while the invalid entries are silently omitted.
The tested libxkbcommon version instead accumulates parse errors and eventually rejects the complete table. Current upstream also explicitly identifies additional result keysyms as invalid in its Compose parser.
Suggested fix
Remove additional result keysyms and keep the full Unicode output in the quoted string, consistently across all generated files:
The complete include tree could be validated in CI with:
LC_ALL=en_US.UTF-8 \
xkbcli compile-compose --test Compose
These files also have sequences longer than 10 keysyms, which are invalid in X11 and emit warning with libxkbcommon, see: xkbcommon/libxkbcommon#1045.
Problem
Some generated entries contain a UTF-8 result string followed by multiple result keysyms:
The Xlib Compose grammar permits only:
libxkbcommon uses the same model: one optional UTF-8 string and one optional keysym. Extra result keysyms are therefore invalid. Multi-codepoint output should be kept entirely in the string:
This occurs in both
ComposeandLogograms.Reproduction
Errors include:
This prevents Fcitx5 from loading the Compose table. Removing the extra result keysyms from both files fixes it.
Why it may appear to work with Xlib
libX11’s parser also accepts at most one result keysym. On a malformed line, however, it skips to the end of that line and continues parsing, so the collection may appear to work while the invalid entries are silently omitted.
The tested libxkbcommon version instead accumulates parse errors and eventually rejects the complete table. Current upstream also explicitly identifies additional result keysyms as invalid in its Compose parser.
Suggested fix
Remove additional result keysyms and keep the full Unicode output in the quoted string, consistently across all generated files:
The complete include tree could be validated in CI with:
These files also have sequences longer than 10 keysyms, which are invalid in X11 and emit warning with libxkbcommon, see: xkbcommon/libxkbcommon#1045.