fi_FI was setting "x11thislocaledir" to en_US, with the result that its
locale data was written in that locale dir.
Signed-off-by: Chris Ball <cjb@laptop.org>
Oops, cccp aliased cc for question mark. Upper-case it to avoid fail.
Signed-off-by: Will Thompson <will@willthompson.co.uk>
Signed-off-by: Daniel Stone <daniel@fooishbar.org> (sorry)
Only convert to use "ansi prototypes" the functions warned from
compilation with "./autogen.sh --prefix=/usr", on a Linux computer.
Also, only address "trivial" compiler warning fixes in this commit.
The new .gitignore is the output of a command like:
% find . -name .gitignore -exec cat {} \; | sort | uniq
and only the toplevel .gitignore file was kept.
The xkeyboard-config keyboards generate the symbol Udiaeresis, not
U00DC. Make sure the relevant Compose sequences expect the symbol
which the keyboards actually send.
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.
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>
Inspired by bug 11930¹:
Commit 40ed4eef92e31fcf7ea0a436e1a00cdf49484c1b to x11proto added dead_psili
and dead_dasia keysyms. Make use of them in the en_US.UTF-8 and el_GR.UTF-8
Compose files.
This was done with a pair of perl scripts based on the one quoted in the
log for commit c76d30253f.
1] https://bugs.freedesktop.org/show_bug.cgi?id=11930
The code <U1000000D> was used where <U10000DC> was obviously intended.
It is possible that <Udiaeresis> should be used instead, if that will
not break anyone’s setup.
From bugzilla bug 10943¹:
There are several Catalan locale codes which presently can
be used in X11 systems; especially after they were accepted
in belocs-locale-data².
In the following patches, I³ add ca_AD, ca_FR and ca_IT Catalan
locale codes. For instance, without this, using ca_AD (actually
a quite used locale⁴) some applications (eg. Emacs or Skype)
cannot display Catalan diacritic marks as you type them.
1] https://bugs.freedesktop.org/show_bug.cgi?id=10943
2] http://lists.debian.org/debian-devel-changes/2005/07/msg01429.html
3] Toni Hermoso Pulido <toniher@softcatala.org>
4] https://launchpad.net/~ubuntu.cat/+members
The description from bugzilla bug 7417¹ is:
We've been shipping this patch for some time in Debian now. The
problem description from the patch header is reproduced below. You
may want to note the licensing issue mentioned below, but we've been
shipping it because the method by which this particular patch was
generated and updated was also given below.
This patch by Denis Barbier.
The X11 protocol states that Unicode keysyms are in the range
0x01000100 - 0x0110FFFF. If the result of composing characters is a
Unicode codepoint, X returns the corresponding Unicode keysym, which
is its Unicode codepoint augmented by 0x01000000. Latin-1
characters must not appear with their Unicode codepoints in compose
files, otherwise the returned composed character lies in the range
0x01000000 - 0x010000FF which is not valid.
There are two solutions: either fix composing routines to return
0xZZ instead of 0x010000ZZ (where Z is an hexadecimal digit), or
replace U00ZZ by their corresponding keysyms in compose files. The
latter is more logical and less error prone, so compose files will
be patched. Many applications accept these invalid Unicode keysyms,
but few of them don't, most notably xemacs. Only UTF-8 locales are
affected.
This has been fixed very recently in XFree86 CVS (but not xorg), but
for licensing reasons, this patch is not grabbed. Instead automatic
conversion is performed by:
sed -e '/XK_LATIN1/,/XK_LATIN1/!d' /usr/include/X11/keysymdef.h \
| grep -v deprecated | grep 0x0 \
| sed -e 's/0x0/U0/' -e 's/XK_//' \
| awk '{ printf "s/\\b%s\\b/%s/ig\n", $3, $2; }' > sedfile
for f in nls/*.UTF-8/Compose.pre
do
sed -f sedfile $f > $f.tmp && mv $f.tmp $f
done
[I edited the quoted script to update it for the current location of
the installed keysymdef.h and the current layout of the libX11
repo. -JimC]
I applied the script, not the patch attached to the bugreport.
1] https://bugs.freedesktop.org/show_bug.cgi?id=7417
