When the compose file is a symbolic link, take the link itself's
modification time into account (in addition to its target's) in
determining whether to invalidate the compose cache.
This is useful e.g. on NixOS systems where the compose file might point
to a store path with an irrelevant modification time, and we want the
cache to expire when the symlink itself changes.
(cherry picked from commit 22f5236943)
Don't warn about Compose file constructs we don't
support. We haven't supported these for a long time,
and nobody has every complained. No need to wake
up sleeping dogs.
X11 allows keysyms to be specified in addition to strings.
We only support the strings. In the past, we ignored everything
after the string. Go back to doing that, but issue a warning
that we've ignored the keysym.
Improve compose sequence handling:
- Show preedit for compose seqences
- Support sequences of up to 20 code points
- Warn when ignoring Compose file features
- Support compose sequences producing multiple characters
- Support hex escapes
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
