makekeys needs to be run during the build process, as opposed to on the
target, so build it with either of gcc or cc to fix cross-compiling.
This can be overridden by setting $CC_FOR_BUILD.
The <dead_acute> <C> and <dead_acute> <c> lines in the pt_BR UTF-8
Compose file show "Ç" and "ç" (c with cedilla accent) (akin to the
ISO 8859 pt_BR Compose file) as the string but specify the keysym
and comment for Ć and ć (c with acute accent).
This commit normalizes those two lines to match the specified string.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=4671
Signed-off-by: James Cloos <cloos@jhcloos.com>
Unicode 1.1 added thirds, fifths, sixths and eights;
we might as well catch up.
(Unicode and ISO 10646 have 1/7 (U2150), 1/9 (U2151), 1/10 (U2152)
and 0/3 (U2189) in their pipelines, but those four can be added
here after they are published.)
As reported in <https://bugs.freedesktop.org/show_bug.cgi?id=17228>:
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 already was:
<Multi_key> <apostrophe> <comma> : 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.
The last commit missed the el_GR UTF-8 Compose.pre as well as
the various ISO 8859 locales which have compose sequences
generating ‘WITH CEDILLA’ characters.
(Interestingly, some of the 8859 locales already supported
<Multi_key> <cedilla> for some CEDILLA characters, but not
for Ç or ç.)
This is further work on bug 10397.
The en_US and pt_BR UTF-8 Compose tables had support for using <comma>
with <Multi_key> to enter CEDILLA characters. Bug 10397 requests
support for using <cedilla> instead of <comma> in said sequences.
This commit makes both styles work.
For network transports, there's enough delay in the network layer
already without adding more. For local transports, just hurry up
and fail if the server isn't there.
I refuse to take any responsibily for this code. It works, I guess.
But - all the flushing is done somewhere before that, so we might need to
flush here. Under some circumstances anyway. Don't ask me, I'm an optical
illusion.
Build with xcb as transport layer highly recommended.
Commit 6b6caeea83 added <dead_belowdot>
<A> and <dead_belowdot> <a> compose sequences for letters U+1E00 and
U+U1E01 (LATIN CAPITAL/SMALL LETTER A WITH RING BELOW). This caused
duplicate compose sequences since these have already been defined. Also,
using <dead_belowring> is more logical since the diacritic is indeed
a "RING BELOW".
No-one uses 8859-5 anymore, so make the default for Russian UTF-8; the
only other possible answer would be KOI8-R.
Signed-off-by: Sergey V. Udaltsov <sergey.udaltsov@gmail.com>
When looking at Thai input methods, make sure XMODIFIERS is checked
before jumping straight into built-in Thai processing, so external XIM
servers such as SCIM can be used with Thai.
If given many requests without replies, Xlib may not sync until it flushes
the output buffer. Thus, if Xlib can fit enough requests in the buffer to
pass by the number of requests it would normally sync after (65536 -
BUFSIZE/sizeof(xReq)), it will sync too late. The test case in bug 15023
demonstrated this by issuing a request with a reply (ListExtensions) at
just the right time to get confused with the GetInputFocus reply issued in
response to the sync 65,536 requests later; the test case used an async
handler to watch the replies, since otherwise it could not issue a request
without waiting for the response. When the test case failed, Xlib's sync
handler would eat the ListExtensions reply, and the test case's async
handler would see the GetInputFocus reply.
Fix this by replacing SEQLIMIT with a function sync_hazard() that uses the
buffer size to figure out when the sequence numbers could potentially wrap
before the next flush.
With this commit, the test case consistently passed, and the async reply
handler always saw the ListExtensions reply.
Commit by Jamey Sharp and Josh Triplett.
