Commit a6f4bbf7 nls (en_US): remove long compositions that override shorter [...] removed some longer compose sequences because there are shorter ones which take preference over the longer. For example the sequences <Multi_key> <apostrophe> <comma> <c> : U1E09 <Multi_key> <apostrophe> <comma> <C> : U1E08 were removed becase there alreade was <Multi_key> <apostrophe> <comma> defined for U201A. Then commit 4ba09125 Work on making the en_US and pt_BR UTF-8 Compose as similar as possible added exactly the same key sequences again. Obviusly they won't work.
<mode="brown paper bag"> D’oh! Thanks for noticing that. I’ll push out a fix. </mode>
I suggest running a command like sed -rn 's/^(<[^:]*>)\s*:.*$/\1/p' Compose.pre \ | sort >keyseqs.txt before and after changing Compose files and then comparing the outputs with diff command. Files consist of just compose sequences in sorted order and from the diff one can see if duplicates or conflicting sequences were added.
Commit a788792e9de95f8db0639557859722a35087481d repairs that damage. The same issue remains, however, for pt_BR.UTF-8/Compose.pre, where it has existed since before the switch to Git. Any thoughts on whether the U1E08/U1E09 or the U201A sequence should be removed there? I have no idea which is more useful for pt_BR users.... (Leaving open pending changes to pt_BR.UTF-8/Compose.pre.)
James, do changes still need to be made for pt_BR.UTF-8? If so, can you please make them or close this bug as FIXED?
I think the changes are in. I’ll confirm and update.
> --- Comment #4 from Jeremy Huddleston <jeremyhu@freedesktop.org> 2011-10-03 01:19:18 PDT --- > James, do changes still need to be made for pt_BR.UTF-8? If so, can you please > make them or close this bug as FIXED? > I believe Xlib's make check complains about stuff like that, so this should be fixed.
> I believe Xlib's make check complains about stuff like that, so this > should be fixed. Indeed. It runs libX11/nls/compose-check.pl to do that. As of my last pull, the only conflict is in iso8859-1/Compose.pre: Clash with existing sequence in iso8859-1/Compose.pre on line 661: Ctrl<T> <A> <A> line #661: Ctrl<T> <A> <A> : "\305" Aring line #480: Ctrl<T> <A> <A> : "@" at which only gets used if USE_CTRL_SHIFT_T_SEQS is #defined. Ctrl<T> is used as a poor-man’s Multi_key in that section, so line 480 is a typo; it should be: Ctrl<T> <A> <T> : "@" at to match the Multi_key sequence in that file. I pushed a fix for that as f858f3326a. I beleive this can be CLOSED now.
(In reply to comment #7) > I beleive this can be CLOSED now. Doing so.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.