Revert ü convertor; implement Chinese qwerty layout; optimize punctuation input.

[AstroNot233]

@abb128

• Revert ü convertor
• Implement Chinese qwerty layout
• Optimize punctuation input
  Modified schema collection is at futo-zh-zidian. Clone and use ./export.sh [version_name] to get .dict file.

Btw, I have a question:

android-keyboard/java/src/org/futo/inputmethod/engine/general/ChineseIME.kt

Line 208 in 2d5841d

rime.simulateKeySequence(string.filter { it in 'a'..'z' || it in 'A'..'Z' })

What does this actually do? I am confused by clearing it and inputting it again. And on my device, it seems to be buggy: after clicking preedit bar, every input behavior will be super strange.

[AstroNot233]

@abb128 Hello! Do you mind that I rewrite floating preedit preview? Especially editing, which I think is not that useful: we can learn from Japanese, using arrow keys to move cursor, in order to avoid complicated preedit preview processing.

Rime doesn't support "move cursor to x", but allows "move cursor by x". This is because when cursor is at, like "你|hao", then tap DPAD_LEFT, it will automatically undo the selection of "ni", and preedit will be "ni|hao". Do once again, some schemas get "|nihao", some get "n|ihao". This makes it hard to process when user select a word, then tap the middle of that word. So the best practice is, only displaying caret positions(I added getting caretPos in RimeJNI), allowing LR moving instead of clicking to move.

[abb128]

@AstroNot233 Samsung and iOS support tapping to move and it seems more convenient so I'd prefer tapping to be supported. Haven't seen any that use arrows, it's more of a Japanese thing. Plus Japanese also supports tap to move

[AstroNot233]

@AstroNot233 Samsung and iOS support tapping to move and it seems more convenient so I'd prefer tapping to be supported. Haven't seen any that use arrows, it's more of a Japanese thing. Plus Japanese also supports tap to move

@abb128 I downloaded Trime and Fcitx5. Trime supports clicking to move cursor but has very low precision; Fcitx5 doesn't allow that at all.

Due to that Rime itself doesn't allow to set caret position, I can only use while scope to send XK_Left or XK_Right. Here is the complexity:
Take 你好shi jie| as pre-edit for example. (the space between shi and jie is auto inserted by luna-pinyin)
The tuple (x, y, z) after preedit is for (caretPos, selStart, selEnd), which is provided by Rime. selStart and selEnd mean candidates are given based on this closed interval.

• (Origin) 你好shi jie caret=9; sel=[2,9]
• XK_Left -> 你好shi|jie caret=5; sel=[2,5]
  No space, and auto skip a full word. Candidates are given based on shi.
• XK_Left -> 你好|shi jie caret=2; sel=[2,9]
  When caretPos == selStart, selEnd == preedit.length.
• XK_Left -> ni hao|shijie caret=6; sel=[0,6]
  Undo selection, now selStart falls back to 0, so selEnd is set to caretPos.
• XK_Left -> ni|haoshijie caret=2; sel=[0,2]
• XK_Right -> ni h|aoshijie caret=4; sel=[0,4]
  Only move one letter, candidates match ni h*

This makes it very hard to calculating now many left shifts is needed when a user click the # marked position in ni h#ao shi jie|. What's more, notice that fa# lü| is expected to be fa|lv after moving. This hacks using detecting substring as while scope condition. For other schemas, what if some expand v to zh, some compact ng to ŋ?

You don't need to fully understand them, since you cannot change this behavior after all. Rime is initially designed for PC, so only uses Left and Right to move caret. Trime seems to try estimating but very inaccurate, sometimes left-shift can be correct, but never for right-shift.

So maybe rather than estimating, directly sending shift+Tab to Rime (Left shift by words) when tapping floating preedit, sending Tab to Rime (Right by words instead of letters) when long press can be prettier and much easier to implement.