数字の区切り記号と中黒にピリオド・スラッシュ候補を追加する - #367
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 560b2924f9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let separatorCandidates = NumericSeparatorCandidates.variants(for: self.composingText.convertTarget) | ||
| .filter { !separatorTexts.contains($0) }.map { text in | ||
| Candidate( | ||
| text: text, value: -18, | ||
| composingCount: .inputCount(self.composingText.input.count), |
There was a problem hiding this comment.
After the user adjusts the conversion segment (for example, shrinking 10・10 to a prefix with Control-I), convertTarget still contains the entire composition while the converter's mainResults represent the edited prefix. This code nevertheless creates 10/10 from the whole target and gives it an input count covering the whole composition, so selecting it ignores the requested segment boundary and commits all remaining text. Derive the variant and composing count from the active conversion range, or suppress these synthetic candidates while segment editing is active.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
🟢 Approval recommended
追加ロジックが入力全体を厳密に数字のみへ限定しており、候補挿入も重複排除されていて新規テストで主要ケースが検証されています。
Pull request overview
入力中の数値区切り（「。」/「・」）および単独の中黒に対して、記号の別表記候補（「5。1→5.1」「10・10→10/10」「・→/・→／」）を候補として提示できるようにし、文中の句点/中黒などは対象外となるようフィルタリングする変更です。
Changes:
- 数値区切り/単独中黒から候補表記を生成する
NumericSeparatorCandidatesを追加 SegmentsManagerの変換候補に区切り記号候補を重複排除して挿入- 上記のユニットテスト＋
SegmentsManager経由の統合寄りテストを追加
File summaries
| File | Description |
|---|---|
| Core/Sources/Core/InputUtils/NumericSeparatorCandidates.swift | 区切り記号の別表記候補生成（数字のみ・空グループ除外・全角数字正規化）を実装 |
| Core/Sources/Core/InputUtils/SegmentsManager.swift | requestCandidates の結果に対し、区切り記号候補を重複排除して上位に挿入 |
| Core/Tests/CoreTests/InputUtilsTests/NumericSeparatorCandidatesTests.swift | 変換ロジックの単体テストと、候補保持/全体確定の動作確認テストを追加 |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
これはAzooKeyKanaKanjiConverterの側で検討したいので、そちらにPRいただけると 🙏 |
5。1→5.1、10・10→10/10、単独の・→/と／を候補へ追加します。数字の全角・半角に対応し、文章中の句点や中黒は対象外です。
検証
不正な区切り・文章の除外・元候補維持・重複・全体確定をテスト。
このブランチ単独で
swift test --package-path Core --jobs 4を実行し、Coreの70テストが成功しました。git diff --checkも成功しています。検証は各ブランチ単独で実施しています。並行実行時に既存の設定共有テストが一度失敗したため、単独再実行で成功を確認しました。
変換範囲と処理負荷
文節編集中は選択中の範囲だけから候補を作り、その範囲だけを確定します。残りの文字は未確定で保持します。候補が空の場合の重複チェックは省略します。