fix: 予測候補を Tab で受け入れても、窓に出ていた候補が無視される問題を修正

[shiina-archelon]

Closes #361

修正

Tab を押したとき、その時点で窓に出ていた候補の表記を SegmentsManager が覚えておき、marked text を決めるときにそれを使う。

• SegmentsManager.acceptedPredictionDisplayText に、Tab を押した時点で窓に出ていた候補の displayText を持つ
• getCurrentMarkedText で、この値があればライブ変換の第一候補より優先して表示する。Enter で確定されるのもこの表記になる
• lastOperation の didSet で値を捨てる。次の入力・削除・文節編集が起きた時点で固定が外れる
• 候補を適用する処理 (deleteCount 分の削除と appendText の挿入) を ConverterServer+KeyEvent から SegmentsManager.acceptPredictionCandidate へ移し、表記を覚えるのと同じ場所で行う

確認

• Core swift test pass
• swiftlint --strict pass
• 手元で確認: 「開発中の予測入力を有効化」ON で ひだ と打ち、予測候補の窓に ← が出た状態で Tab を押すと、変換中テキストが ← になり、Enter で ← が確定された

[ensan-hcl]

すみません、この修正をazooKey-Desktopのレイヤーでやるのは変なので、AzooKeyKanaKanjiConverter側で対応したいです。具体的には、AzooKeyKanaKanjiConverterが持っているprefix constraintをタブ予測候補で保管するような形があり得ると思います。

[shiina-archelon]

@ensan-hcl 回答ありがとうございます。

この修正をazooKey-Desktopのレイヤーでやるのは変

これでTabで「←」を確定しても
のように、次の候補が確定した「←」を尊重しないのは、Desktopでごまかしてるからってことですね。

具体的には、AzooKeyKanaKanjiConverterが持っているprefix constraintをタブ予測候補で保管

別リポジトリの方は、APIメソッド追加してprefix constraint編集して、変換部分ごにょごにょしたら(たぶん)動いているのであっちにPR出します。

[shiina-archelon]

@ensan-hcl
レビューコメントを受けて以下の変更をpushしました。

--

Converter 側に azooKey/AzooKeyKanaKanjiConverter#357 を出しました。それを呼ぶだけの形に差し替えています。

変えたところ

• SegmentsManager.PredictionCandidate に、表示のもとになった Converter の候補 candidate を持たせる
• SegmentsManager.acceptPredictionCandidate(:) を足し、Converter の KanaKanjiConverter.setPrefixCandidate(:) へ渡す
• ConverterServer の Tab 処理で、読みを補完する前に呼ぶ

注意点

Core/Package.swift は、AzooKeyKanaKanjiConverter 側が固まらないと正しく書けないので、そのままにしてあります。したがって、正しい値を入れるまで、この branch は build できません。

確認

• swift test --package-path Core --filter Prediction: 9 件 passed (AzooKeyKanaKanjiConverter をローカル参照にして確認)
• 実機で hida → Tab (←) のあと第一候補が 「←」を利用するようになった
  ここの部分で「←」をTabで選んだ後の 予測候補が 「左」で始まってしまっていたのが改善した