Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

候補入力時にカーソルを使えるようにする #156

Open
naokiri opened this issue Jun 11, 2022 · 2 comments
Open

候補入力時にカーソルを使えるようにする #156

naokiri opened this issue Jun 11, 2022 · 2 comments

Comments

@naokiri
Copy link
Owner

naokiri commented Jun 11, 2022

▼ぞうご【ここ】
この【】内でカーソルが使えると嬉しい。

現在の仕様
fcitx-cskkではlibskkを使ったものと同じ挙動
IMEからはカーソル位置は変更されていない状態でpreeditの文字列が変わるだけなので、カーソル位置は常に】の後
新変換候補入力時にカーソル移動をしようとしても、無視される。
例として辞書内に「ぺ」の変換候補がない時|をIMEのカーソルとすると
P e space a a a -> ▼ぺ【あああ】|
P e space a a a leftarrow -> ▼ぺ【あああ】|
また、新変換候補入力に限らず、
A i leftarrow -> ▽あい|
と、カーソル位置は常に未確定文字列の後となっている。

できるのかどうかわからないが
IME側でのカーソル位置を変更できそうであれば
P e space a a a -> ▼ぺ【あああ|】
P e space a a a leftarrow -> ▼ぺ【ああ|あ】
のようにpreedit文字列の中にカーソルを移動させたい。
参考例としてはWindowsのSKKFEPでは
A i leftarrow -> ▽あ|い
のようにカーソル位置が動く。

fcitx および ibusどちらでもそのような想定がないならば新変換候補入力の時のみ独自にカーソルをもつしかない。

@naokiri naokiri changed the title 新変換候補入力時にカーソルを使えるようにする 候補入力時にカーソルを使えるようにする Jun 11, 2022
@naokiri
Copy link
Owner Author

naokiri commented Jun 26, 2022

https://wayland.app/protocols/input-method-unstable-v1
このあたりのwayland protocolがよく安定したらcskk側ではなくIME plugin側でカーソル移動も可能だと思われる。
このissueと直接関係はないが、例に使っているSKKFEPのようにpreedit_styling対応してモードによってstyling変えたりも可能となりそう。

@naokiri
Copy link
Owner Author

naokiri commented Aug 19, 2022

まずはanchor==cursor、つまり範囲選択のないsurrounding text対応として実装を始めたい。連文節変換をしないSKKにおいて範囲変更や中途の範囲のみを対象とする操作が意味を成す仕様が考えられないため、anchor!=cursorの範囲選択は対応しない方針。

第一段階はskkstateをきちんとcontextと分離し、state内部操作がcontextから行なわれないようにリファクタリング、contextからの無茶な操作でstateの状態が矛盾を起こさないようにする。
第二段階としてstateがcursor位置を持ち、surrounding textに対応したメソッドを持ち、内部的にsurrounding textそのものの文字列を持たずとも操作できるようにしたい。

まずは実現可能かどうかわからないが想定する仕様として

  • Directモード
    surrounding textはかな変換中の文字列を含めてさすことにする。つまり、「かきくけこ」を入力中「かきk」の段階で「かきk」がsurrounding textで、kの後にcursor。ただし、通常はIMEで各かな文字のcommitが入るので現実的にはRegisterモードでない限り「k」のみがsurrounding textとなり、cursorがその直後となる。

surrounding textのカーソル位置を変えること自体に非対応か、かな変換の中途で文字を変えたい需要を想定できないので変えた時に変換前の文字列をそのまま入力したことにして対処か、あるいはかな変換前の文字列を消してから対処か。
先の例だと前者ではkがあたかもLatinで入力されて「かきk」がそのまま内部ではcommitされてからcursor変更を開始したとみなす、後者ではkがクリアされて「かき」に対して範囲変更を開始したとみなす。(通常のIMEで各文字のcommitが入るとすると、実質cursor位置変更に非対応と同じ。)
libskkの実装例を確認するが、後述するPrecompositionOkuriganaと仕様が違うと混乱するのでかな入力前の文字を消すかどうかは合わせたい。

  • Precomposition,(Abbrev)モード
    surrounding textは変換対象文字列、モード表示含まない。「A i」から 「▽あい」を例とすると「あい」がsurrounding textでcurosrはその直後。
    cursor変更はanchorを無視してcursor位置のみ変更可能にして、cursor位置に入力できるようにしたい。例として「A i ← t a」で「▽あたい」となるように。

cursor位置が末尾でない場合に大文字を入力した時には
A. 送り仮名開始とみなさずに入力とする
B. cursor位置から末尾を消去してその部分から送り仮名をはじめる
C. cursor位置を無視して強制的に末尾に移動させ、送り仮名をはじめる
等が考えられる。参考としてWindowsのSKKFEPは仕様C。

  • PrecompositionOkuriganaモード
    理想としてはOkurigana時にもOkuriganaのままcursor位置変更できたらいいが、カーソル位置が*の前か直後か送り仮名文字の後かと入力なのか消去なのかで挙動が大きく変わるので非常に難しい。参考にしているWinのSKKFEPでもバグなのか仕様なのかわからない挙動をする。
    カーソル位置変更の際にはokuriを消去してPrecompositionモードに戻すか、一切無視するか。

  • CompositionSelectionモード
    一応現在の選択肢がsurrounding_textで、cursorがその直後だが、cursor位置変更等を一切しない、無視する。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant