uim-skk does'nt handle "nq" key sequence properly in kana-mode. The expected behavior is: 1. commit "n" as hiragana or katakana (according to input mode) 2. switch kana-mode by "q" (hiragana to katakana, or reversely) But current implementation is: 1. commit "n" as hiragana or katakana (according to input mode) 2. "q" triggers committing "n" and simply discarded See [Anthy-dev 609] and [Anthy-dev 622].
Fixed by r738. * skk.scm: - (skk-get-string-by-mode): Split into two procedures - (skk-get-string): New procedure. Forms string from skk-context by arbitrary kana type - (skk-append-residual-kana): New procedure - (skk-begin-conversion): Clean up using skk-append-residual-kana - (skk-proc-state-direct): * Handles "nq" key sequence as below. This is ddskk-compatible behavior. This has resolved bug #500 1. commits "n" as kana according to kana-mode 2. switch kana-mode by "q" (hiragana to katakana, or reversely) * Handles "n " key sequence as below. This is ddskk-compatible behavior. 1. commits "n" as kana according to kana-mode 2. commits " " as native space (such as Qt::Key_Space) * commits "n" as kana according to kana-mode on skk-commit-key?. This is ddskk-compatible behavior. * Add some comments involving bug #528 - (skk-proc-state-kanji): * commits pending "n" as kana on skk-commit-key? or skk-return-key? * commits pending "n" as kana on skk-kana-toggle-key?. This has resolved bug #500 * Clean up using skk-append-residual-kana
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.