Skip to content

補完エンジン連携を登録制にする - #253

Merged
Shougo merged 4 commits into
vim-skk:mainfrom
delphinus:feat/completion-backend
Sep 10, 2026
Merged

Shougo merged 4 commits into
vim-skk:mainfrom
delphinus:feat/completion-backend

Conversation

@delphinus

@delphinus delphinus commented Aug 8, 2026 •

Copy link
Copy Markdown
Contributor

#249 で相談していた件です。案 X(デフォルトは native、それ以外はユーザーが明示的に指定する)で実装しました。

変更内容

補完エンジンの自動判定を廃止し、名前で登録・選択する形にしました。

" 補完ソースを提供するプラグイン側で登録します
call skkeleton#register_completion_backend('blink.cmp', #{
  \   complete_info: {-> ...},
  \   confirm_key: "<Cmd>lua require('blink.cmp').select_and_accept()",
  \ })

" ユーザーはどれを使うか選びます
call skkeleton#config(#{ completionBackend: 'blink.cmp' })
  • complete_info(): pum_visible と selected を持つ辞書を返します。
  • confirm_key: 選択中の候補を確定するキーです。<Cmd> で始まる場合はコマンドとして実行されます。

内蔵しているのは組み込み補完 (ins-completion) を扱う native だけで、これがデフォルトです。当初は nvim-cmp / pum.vim も内蔵していましたが、レビューでの指摘を受けて削除しました。バックエンドの定義は追従すべきエンジンの側にあるべきで、そちらが適切だと思います。

併せて skkeleton#vim_status() が confirm_key を返すようにしたので、handleCompleteKey() からエンジン毎の分岐が無くなりました。これで新しい補完エンジンへの対応に本体の変更が要らなくなります。

破壊的変更

補完エンジンを自動判定しなくなります。組み込み補完以外を使っているユーザーは、バックエンドの登録と選択が必要になります。COMPATIBILITY に追記しました。

登録は補完エンジン側で行われるのが前提で、ユーザーは名前を選ぶだけです。

call skkeleton#config(#{ completionBackend: 'blink.cmp' })

エンジン側の状況は以下の通りです。

  • pum.vim: Shougo さんが pum.vim 側で対応してくださるとのことです。
  • blink.cmp: blink-cmp-skkeleton に Draft PR を出しています (下記)。
  • nvim-cmp: cmp-skkeleton に PR を出す予定です。

エンジン側が未対応の間は、ユーザーが 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 の確認は削除した内蔵定義で行ったものですが、同じ内容をエンジン側で登録すれば同じように動きます。

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
delphinus force-pushed the feat/completion-backend branch from e77f0e9 to c5e7b43 Compare August 8, 2026 07:09
@Shougo
Shougo requested a review from kuuote August 9, 2026 03:48
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Shougo

Shougo commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

先に他のプルリクエストをチェックしてからマージするのでこっちのマージはお待ちください

@Shougo

Shougo commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

#249 で話に出ていた通り v3.0.0 でリリースするのが適切かと思います。

そういえば、互換性が崩れるのでバージョン上げないといけませんね

@Shougo

Shougo commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

@delphinus skkeleton のバックエンドについて、nvim-cmp, pum.vim のバックエンド実装は本来それぞれのプラグインに移動させるべきものだと思います。
このプルリクエストからは削除してよいのではないかと考えます。

pum.vim の作業はこっちでやります。

@delphinus

Copy link
Copy Markdown
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>
@delphinus

Copy link
Copy Markdown
Contributor Author

削除しました。nvim-cmp についてのコードは cmp-skkeleton に PR しておこうと思います。

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 Shougo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

日付の修正だけお願いします。

Comment thread autoload/skkeleton.vim Outdated
Comment thread doc/skkeleton.jax Outdated
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@Shougo

Shougo commented Sep 10, 2026

Copy link
Copy Markdown
Contributor

マージします

@Shougo
Shougo merged commit 37f4e76 into vim-skk:main Sep 10, 2026
2 checks passed
@delphinus
delphinus deleted the feat/completion-backend branch September 10, 2026 09:33
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>
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

Successfully merging this pull request may close these issues.

2 participants