補完エンジン連携を登録制にする - #253
Merged
Merged
補完エンジン連携を登録制にする#253
Conversation
delphinus
force-pushed
the
feat/completion-backend
branch
from
August 8, 2026 07:05
1cbc11d to
e77f0e9
Compare
skkeleton auto-detected pum.vim / nvim-cmp / native in s:complete_info() and mapped each of them to a confirm key in handleCompleteKey(). Every new completion engine therefore needed engine-specific code in skkeleton itself (vim-skk#249). Replace the auto-detection with a registry: - skkeleton#register_completion_backend({name}, {backend}) registers a {complete_info: Funcref, confirm_key: string} pair. - native / nvim-cmp / pum.vim are registered as built-in backends. - The new "completionBackend" option selects one by name and defaults to "native". - skkeleton#vim_status() now reports completeConfirmKey, so denops no longer knows anything about individual completion engines. An unregistered name falls back to native silently and is reported once from skkeleton-enable-post. skkeleton#handle() evaluates skkeleton#vim_status() before the denops round-trip that fires skkeleton-enable-pre, so a backend registered from that hook is missing on the very first key press; nothing depends on the answer there because no completion menu can be open yet. Diagnosing at enable-post lets a completion source register from the hook skkeleton already documents. BREAKING CHANGE: the completion engine is no longer detected automatically. Users of pum.vim or nvim-cmp must set completionBackend. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
delphinus
force-pushed
the
feat/completion-backend
branch
from
August 8, 2026 07:09
e77f0e9 to
c5e7b43
Compare
Shougo
approved these changes
Aug 9, 2026
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
先に他のプルリクエストをチェックしてからマージするのでこっちのマージはお待ちください |
Contributor
そういえば、互換性が崩れるのでバージョン上げないといけませんね |
Contributor
|
@delphinus skkeleton のバックエンドについて、
|
Contributor
Author
|
なるほど。その方が一貫性がありますね。実装を削除します。 |
The point of the registry is that skkeleton stops knowing about individual completion engines, and shipping two of them contradicts it: a backend belongs next to the engine it follows, so that a change there is a change in one place. Only "native" stays, which has no plugin to live in and is the default. pum.vim is getting the registration on its own side, and anything else is registered by the engine -- or by the user until it is. Nothing else changes: an unregistered name still falls back to "native" and says so once. Requested in the review of vim-skk#253. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
削除しました。nvim-cmp についてのコードは cmp-skkeleton に PR しておこうと思います。 |
Merged
delphinus
added a commit
to delphinus/cmp-skkeleton2
that referenced
this pull request
Sep 9, 2026
skkeleton no longer detects the completion engine on its own (vim-skk/skkeleton#253). It takes a named definition through skkeleton#register_completion_backend() and lets the user pick one, so the definition for nvim-cmp has to come from somewhere. Here is the natural place: it follows nvim-cmp's API, which is what this plugin already does. Registration happens on skkeleton-enable-pre, the hook skkeleton documents for setting itself up, and that is early enough because the backend is only consulted while a completion menu is open. It is a no-op for users who do not select this backend, and pcall keeps it quiet on a skkeleton that predates the API. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Shougo
requested changes
Sep 9, 2026
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
マージします |
delphinus
added a commit
to delphinus/dotfiles
that referenced
this pull request
Sep 15, 2026
skkeleton の統合ブランチが e678b8f まで進んだので lock を追随させる。 補完で確定した分も kakuteiUndo で取り消せるようになった (e087379)。 これには completeCallback へ挿入文字列を渡す blink-cmp-skkeleton 側の 対応が要るので、branch pin を feat/kakutei-undo-inserted に切り替える。 vim-skk/skkeleton#253 と #255 は upstream にマージ済み。統合ブランチは マージ後の upstream を取り込んだ形になっている。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
delphinus
added a commit
to delphinus/dotfiles
that referenced
this pull request
Sep 15, 2026
skkeleton 本体から nvim-cmp / pum.vim の backend 定義が外れた (vim-skk/skkeleton#253) ので、その受け皿を core/skkeleton_cmp.lua に書いて いたが、同じものを cmp-skkeleton へ PR 済み (uga-rosa/cmp-skkeleton#4) なので そちらを使う。定義は追従すべき補完エンジンの側に置く、という #253 の方針にも こちらが沿っている。blink 側で blink-cmp-skkeleton がやっているのと同じ形。 fork のレポジトリ名が cmp-skkeleton2 なので、name でプラグイン名を元に揃える (lazy-lock.json のキーと lua のモジュール名を変えないため)。マージされたら branch 指定を外して "uga-rosa/cmp-skkeleton" に戻す。 PR 側は skkeleton-enable-pre で once に登録し、pcall で包んである。設定に 書いていた版は skkeleton の config 内で即時に呼んでいたが、backend は補完 メニューが開いている間しか参照されないのでどちらでも間に合う。 CMP=1 の時だけの経路なので、既定の blink には影響しない。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
delphinus
added a commit
to delphinus/dotfiles
that referenced
this pull request
Sep 15, 2026
補完エンジン連携を登録制にする変更 (vim-skk/skkeleton#253) が upstream に マージされたので、それと確定アンドゥを載せた統合ブランチ test/completion-backend+kakutei-undo が要らなくなった。確定アンドゥだけを main の最新に載せ直した feature/kakutei-undo-invalidation に切り替える。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#249 で相談していた件です。案 X(デフォルトは native、それ以外はユーザーが明示的に指定する)で実装しました。
変更内容
補完エンジンの自動判定を廃止し、名前で登録・選択する形にしました。
complete_info():pum_visibleとselectedを持つ辞書を返します。confirm_key: 選択中の候補を確定するキーです。<Cmd>で始まる場合はコマンドとして実行されます。内蔵しているのは組み込み補完 (
ins-completion) を扱うnativeだけで、これがデフォルトです。当初はnvim-cmp/pum.vimも内蔵していましたが、レビューでの指摘を受けて削除しました。バックエンドの定義は追従すべきエンジンの側にあるべきで、そちらが適切だと思います。併せて
skkeleton#vim_status()がconfirm_keyを返すようにしたので、handleCompleteKey()からエンジン毎の分岐が無くなりました。これで新しい補完エンジンへの対応に本体の変更が要らなくなります。破壊的変更
補完エンジンを自動判定しなくなります。組み込み補完以外を使っているユーザーは、バックエンドの登録と選択が必要になります。
COMPATIBILITYに追記しました。登録は補完エンジン側で行われるのが前提で、ユーザーは名前を選ぶだけです。
エンジン側の状況は以下の通りです。
エンジン側が未対応の間は、ユーザーが
skkeleton#register_completion_backend()を自分で呼んでも同じことができます。#249 で話に出ていた通り v3.0.0 でリリースするのが適切かと思います。
関連
#251 との関係を確認するため、手元でこのブランチにマージして試してみましたが、正しく動作し、コードもコンフリクトしません(
doc/skkeleton.jaxの*skkeleton-completion*節だけは両方の追記を並べる必要があります)。マージはどちらが先でも問題ありません。blink.cmp については blink-cmp-skkeleton 側に Draft PR を出しています(Xantibody/blink-cmp-skkeleton#21)。
確認
completion_backend_test.tsを追加しました。手元では blink.cmp / ddc-ui-native / ddc-ui-pum + pum.vim / #251 completefunc の 4 構成で、eggLikeNewlineの<CR>による確定を確認しています。pum.vim の確認は削除した内蔵定義で行ったものですが、同じ内容をエンジン側で登録すれば同じように動きます。