Neovim の言語サービス、補完、整形

色付け、補完、定義への移動、テスト実行は別の機能から来る。機能が失敗したら、再導入の前に担当を特定する。

ファイルを開くと動く層

extra はこの一部を接続する。optional は対象プラグインが導入されている場合に設定され、SDK や依存関係は別に用意する。LazyVim extras

一つの言語から確認する

Rust なら先に端末で cargo check を通し、:LazyExtras で Rust を有効化する。ツールチェーンや依存取得の失敗をエディタだけの問題にしない。

Cargo プロジェクト内の Rust ファイルで確認する。

:set filetype?
:pwd
:lua print(vim.inspect(vim.lsp.get_clients({ bufnr = 0 })))

rust と関連クライアントが期待値。:pwd はエディタの場所であり、LSP のルートとは限らないためクライアント設定も見る。Neovim LSP

外へコピーした単独ファイルにはモジュールや依存の文脈がない場合がある。workspace は外側をルートにすることもある。

機能ごとに検証する

既知のローカル関数で定義、参照、hover、名前変更を試す。キーと API を切り分ける直接呼び出し：

:lua vim.lsp.buf.definition()
:lua vim.lsp.buf.references()
:lua vim.lsp.buf.hover()

結果なしでも、未解決の依存や索引途中の可能性がある。まず確実なローカル対象で基準を作る。名前変更後は対象 buffer を確認して保存し、Git diff を読む。

誰が整形するか

LazyVim では Conform がよく使われる。:ConformInfo で対象 formatter、実行可能性、ログを調べる。学習時は options.lua で自動整形を止められる。

vim.g.autoformat = false

必要時に手動整形し、プロジェクトの .editorconfig、.clang-format、rustfmt.toml を尊重する。

lua/plugins/formatting.lua の例：

return {
  {
    "stevearc/conform.nvim",
    opts = function(_, opts)
      opts.formatters_by_ft = opts.formatters_by_ft or {}
      opts.formatters_by_ft.lua = { "stylua" }
    end,
  },
}

これは StyLua の選択であり、導入ではない。保存イベントで別途 LSP 整形を重ねると、重複処理や規則競合を起こし得る。

診断、テスト、デバッグ

構文や型が正しくても要件の境界を誤ることがある。修正課題で違いを確認する。

デバッグには起動対象、場所、引数、adapter が必要となる。同じ対象がコマンドラインで動くことを先に確認する。nvim-dap だけで全言語のバックエンドが揃うわけではない。

調べる順序

1. filetype を確認する。
2. プロジェクトの範囲、設定、依存を確認する。
3. :lua print(vim.fn.exepath("rust-analyzer")) などで実行パスを見る。独自パスを持つプラグインも確認する。
4. クライアント附着と起動ログを見る。
5. 対象機能への対応とファイル固有の条件を調べる。
6. 整形とデバッグは各自のツール・ログで切り分ける。

一度に一条件を変更し、小さなプロジェクトとログで説明してから通常設定へ戻す。