Fourteen years ago, commit 73029846 added some four hundred compose
sequences for the benefit of the French Bépo layout.  But among these
four hundred there are several that use symbols that are not available
in the Bépo layout and are thus impossible to type.  Some of the used
symbols, like Ahook, Ehook and Ohook, are not even present in *any*
layout, making these sequences a dead weight in the Compose file.

The Amacron and Omacron are available only in the Latvian, Hawaiian,
and Maori layouts, and the Omacron also in the Silesian layout.  But
the Latvian layouts and the Hawaiian do not contain any dead keys.
Only in the Maori and Silesian layouts these sequences with Amacron
and Omacron could be typed, but that was not why they were added.

More importantly, as James Cloos noted in issue #54, sequences like
`<dead_abovedot> <amacron>` for generating `ǡ` (that is: the macron
above the dot) are questionable, as in compose sequences generally
the first accent typed is the uppermost in the composed character.

Reference:
  #54 (comment 17321)

Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>

Also, uncapitalize two arguments, to match the style of all others.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Seventeen months ago, commits 78027fdb and 4f15cfc6

 removed
these dashes from two of the man pages.  Now, remove them all.
They are unhelpful and just make one wonder why they are there
(probably to function as improvised bullet points).

Also remove four leading spaces and a trailing comma.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

(Table 1 hard-wraps the first-column items in the same way.)

Also, correct the formatting of the subsequent paragraph.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Compose sequences for circled numbers, like ⑫  or ㉑, are nice to have,
but allowing them to be composed by typing one digit on the top row and
the other on the numerical keypad (or the other way around) is over the
top.  Remove these absurd sequences.  Keep only the sequences where both
digits are either on the top row or on the numerical keypad.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Prior to this, --enable-thread-safety-constructor would disable it,
while --disable worked as expected, and no option left it enabled as
expected by default.  This also fixes the --help text to be displayed.

Fixes: afcdb6fb
Reported-by: @igor.v.kovalenko

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>

Minor number bump to reflect the thread safety default change.
Signed-off-by: Adam Jackson <ajax@redhat.com>

There is really no point in not being thread safe, I measured, all you
can see happen is noop performance gets like twice as slow and you have
thread safety bugs. And we're using xcb as the transport which means we
should expect threads in our clients anyway. Just do it.

This assumes your compiler understands __attribute__((constructor)). If
this is not your compiler, you can disable this with the appropriate
configure flag, but be aware you're asking for bugs.
Signed-off-by: Adam Jackson <ajax@redhat.com>

They were forgotten when those releases were made.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

The Xserver made its own copy of this file in 2008, and the API's are
no longer the same between the server and client forks.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

(Not that it will make any difference, as the checking of these
high bits looks like an excess of precaution.)

This fixes issue #134

.

Reported-by: Rafał Mikrut
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

In the Ethiopian keyboard layout, the dead vowel keys do not produce <e>
and <u> and so on, but instead produce <U+FE69> and <U+FE75> and so on,
so the compose sequences should use those latter code points.

Also, include the basic compose sequences from en_US.UTF-8/Compose,
so that, when switching to a different layout in the Ethiopian locale,
all the usual compose sequences work too.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

These accents by themselves could only be produced when one had a
dead key for them, not with the help of the Multi key.

[Note that the sequences <dead_acute> <space> for apostrophe (')
and <dead_diaeresis> <space> for double quote (") are anomalies,
as normally <dead_accent> <space> produces the accent itself.]
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Compose sequences are meant to produce certain symbols by combining
certain different symbols, not to produce a symbol with the help of
the symbol itself.

This fixes issue #59

.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

The Khmer digraphs and Arabic ligatures have nothing to do with
Amharic or Greek.

(Also rewrap a comment and correct two others.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

This fixes issue #160

.

Reported-by: Mike Fabian
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

XkbVirtualModsToReal should only fail to set mask if the server does
not support XKB, but it still made Oracle Parfait complain:

Error: Uninitialised memory
   Uninitialised memory variable [uninitialised-mem-var] (CWE 457):
      Possible access to uninitialised memory referenced by variable 'mask'
        at line 863 of lib/libX11/src/xkb/XKBMisc.c in function 'XkbUpdateKeyTypeVirtualMods'.
        Path in callee avoiding write at line 862
          mask allocated at line 860
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

Signed-off-by: Matt Turner <mattst88@gmail.com>

This avoids a segfault during error-unwinding if an invalid display name
is passed to XOpenDisplay().

Fixes: 8a368d80 "Fix two memory leaks in _XFreeX11XCBStructure()"
Resolves: #155

Signed-off-by: Simon McVittie <smcv@debian.org>

Signed-off-by: Matt Turner <mattst88@gmail.com>

Hodong authored Jan 20, 2022 and Matt Turner committed Mar 24, 2022

Even when XCloseDisplay() was called, some memory was leaked.

XCloseDisplay() calls _XFreeDisplayStructure(), which calls
_XFreeX11XCBStructure().

However, _XFreeX11XCBStructure() did not destroy the condition variables,
resulting in the leaking of some 40 bytes.
Signed-off-by: Hodong <hodong@yozmos.com>

XInitThreads has been called if _Xglobal_lock != NULL, we may as well
check that before printing a misleading error message.
Signed-off-by: Adam Jackson <ajax@redhat.com>

Giovanni Mascellani authored Feb 04, 2022 and Matt Turner committed Mar 23, 2022

Request numbers are not always seen in the numeric order by widen(),
for example due to Mesa directly calling _XError(). When this happens,
widen() adds 2^32 to the reported widened number, triggering failed
assertions and bad behavior.

With this commit, wrapping of the lower dword is detected in a more
robust way, by requiring that a skip of at least 2^31 is seen.

This fixes issue #152

.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>

As the thing in the circle looks a bit like an upside-down Y,
use <O> <Y> as the sequence, similar to <O> <A> for anarchism.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Benno Schulenberg authored Feb 25, 2022 and Alan Coopersmith committed Feb 25, 2022

(These aliases may have been useful on some systems twenty years ago,
but nowadays all should have settled on lowercase language code plus
uppercase country code.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

(Debian has had several of these lines commented out for years.)
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

iyzana authored Feb 21, 2022 and Benno Schulenberg committed Feb 25, 2022

There is no matching locale in the locale.dir and compose.dir files for
the locale eo.UTF-8. Setting it as the locale resulted in compose files
not being loaded.
Signed-off-by: iyzana <iyzana@protonmail.com>

Benno Schulenberg authored Feb 03, 2022 and Alan Coopersmith committed Feb 24, 2022

Also, correct the comment for the double quote character ("), and move
the soft hyphen and the interrobangs to a special punctuation group.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Benno Schulenberg authored Feb 03, 2022 and Alan Coopersmith committed Feb 24, 2022

Using a misspelled abbreviation (CCCP) of an obsolete country's name
to compose a fairly general communist symbol does not seem right.

    https://en.wikipedia.org/wiki/Hammer_and_sickle



Many compose sequences instead combine characters that together look
similar to the target character.  Do the same here: question mark (?)
plus backslash (\) look a bit like ☭ .

In the bargain, this fixes issue #63.

Reported-by: Marc Mezzarobba
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

These sequences follow the logic of: the arrow shaft (=) first, the
arrow head (< or > or ^ or v) second.  This is so because the sequence
<= is already taken for ≤, and there is no obvious ASCII character for
a double vertical line, so we have to make do with a horizontal one.

Since commit 6101b967

 from eight years ago, there is a compose sequence
for the rightward double arrow, but not for the other three directions.

This fixes issue #138.

Requested-by: Mélanie Chauvel
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

It is possible for _XimICOfXICID() to return NULL, so it is necessary
to check this isn't actually the case before dereferencing the pointer.
All other callers of _XimICOfXICID() do this check too.

(The check itself is ugly, but it follows the style of the code in the
rest of the module.)

Fixes issue #45

.

Reported-by: Bhavi Dhingra

Original-patch-by: Bhavi Dhingra
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>

Signed-off-by: Christopher Chavez <chrischavez@gmx.us>

Denis Drakhnia authored Feb 02, 2022 and Benno Schulenberg committed Feb 04, 2022

Signed-off-by: Denis Drakhnia <numas13@gmail.com>