One xkb_compose_state served the whole session, so a dead key left half
typed in one window was completed by the first key in the next. Two IBus
contexts through the real processkey(), before this:
want length 0, got length 2; byte 0: want <end>, got 0xc3 (text)
want 0, got 1 (req.op)
Context A pressed dead_acute; context B pressed e, got é, and went down
the composed-text branch instead of sending a key. Only COMPOSING is
sticky -- xkbcommon starts over by itself after COMPOSED and CANCELLED,
which the table in compose_test already pins -- and nothing here ever
called xkb_compose_state_reset.
That static was also fed from three procs, two of them live at once, with
no lock, which xkbcommon forbids. Reaching it needs two focused windows,
so it cannot be made to fail on demand and has no test: it goes because
the sharing goes, not because anything guards it.
So a state per frontend, each starting over when the key comes from
another context. All are made in composeinit(), on threadmain, before
proccreate, because xkb_compose_state_new refs the table and that ref is
a plain increment --
b160: mov (%rdi),%edx b16a: add $0x1,%edx b170: mov %edx,(%rdi)
-- so making a state from a shared table on two procs would race in place
of the feed. Made before the procs exist they can still share the one
table. An owner address that gets reused says so with composedrop: ibus
hands out a contexts[] slot again, xim can malloc an Ic at a freed one,
and wl's single context, which serves every client in turn, drops at
every activate and deactivate.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
An IBus client throws away a dead key its engine did not take — the GTK
module's own comment says so, and Qt does the same — so é and ü were
lost in every IBus application, while XIM composed them with a table of
its own. That table moves to compose.c, which both frontends now use;
xim.c is the shorter for it.
A finished sequence is text, not a key: the engine is asked to hand back
what it had pending, and the composed text follows it, so the composed
character can no longer land before the syllable typed before it.
Cclientpreedit was a one-bit mask that every producer set as "want ?
Cclientpreedit : 0" and every consumer masked out again; nothing else
was ever going to join it. Keyreq carries clientpre, an int that says
whether the client draws the preedit, and the engine and the XIM
context keep it under that name.
An XIM spot has no height, so a popup that flips above it at the bottom
of the screen ended on the baseline and covered the line being typed.
The spot now stands for the row above it, one popup row tall, as GTK
and IBus carets carry their line height; below the spot nothing moves.
win.c and xim.c each iterated the setup's roots to find the screen
xcb_connect had chosen; xcb-util, already linked through imdkit, has
xcb_aux_get_screen for that.
A Compose sequence whose result is more than one character has no
keysym, so xkb_compose_state_get_one_sym gave nothing and the result was
lost; the UTF-8 the compose state holds is committed instead. Clients
that ask for a StatusNone style — fcitx5 offers them — failed to create
an input context; the three preedit styles come in both status flavours
now. IBus SetCursorLocation returned an error for a negative width or
height that nothing reads and no client ever waits for.
xim/keymap.c held one 37-line function apart from xim.c, with its own
prototype typed by hand in xim.c and nelem spelt out because it avoided
dat.h — all so that a test could link it without imdkit, though the XIM
adapter test #includes xim.c whole anyway. It lives in xim.c now, and
xim.c, the last file of its directory, sits beside ibus.c.
