okuriletter() puts じ in the z row, so dictqokuri can never build a key
ending in j. map/kanji.dict has 17 of them, and 8 have no z twin at all:
before after
shinjiru 死んじる 信じる 死んじる
tojiru (nothing) 綴じる 閉じる
tsuujiru (nothing) 通じる
shoujiru (nothing) 生じる
toujiru 問うじる 投じる 問うじる
koujiru 乞うじる 請うじる 高じる 乞うじる 請うじる
gozonji 御存知 御存知 御存じ
majiru 混じる 先じる 交じる 混じる
信じる, 閉じる, 通じる, 生じる, 投じる, 交じる: the dictionary holds every
one and the engine could reach none. What it offered instead was the
next split down -- しんじる falls back to しn, so 死んじる is what the
popup shows for 信じる, and it is the only candidate.
The letter is not ours to choose; it is the one the SKK dictionary was
keyed by, which is the one the user typed. Real SKK carries both spellings
where both are typed, and here that is 9 of the 17 -- えんj/えんz, かんj/かんz
and their kin, identical values on both. Those 8 z rows go unreachable and
lose nothing, because their j twin says the same word. ま is the one pair
that differs, まj=交 混 against まz=混 先, and both stay reachable: じ takes
the j road and ぜ/ず keep the z one.
mazeru 混ぜる 先ぜる unchanged
kanarazu 必ず ... unchanged
mizu 水 見ず unchanged
dekizu 出来ず unchanged
The z row keeps ざずぜぞ, so nothing that is not じ moves.
What this does not cover, deliberately: ち. kanji.dict has 7 keys ending
in c, from users who typed "chi", and okuriletter puts ち in the t row.
Giving c its own row would have to take ち out of t, and t is where the
larger entry lives -- おt is 落 折 負 追 against おc's 落 alone -- so the c
rows stay unreachable and lose nothing. づ needed no such choice: it is
in the d row, もとd is 基, and もとz is its duplicate.
Hojun-Cho
a351f50308