デバッグ
Nvim の :help ページは、生成されており、ソースをtree-sitter-vimdocパーサーを使って解析しています。
Vim のデバッグ
これは、Vim 自体が正常に動作しない場合のデバッグに関するものです。Vim スクリプトや関数などをデバッグする場合は、
debug-scriptsを参照してください。
Vimがテストファイルでクラッシュした場合、コンパイルにgccを使用している場合、Vimがどこでクラッシュしたかを正確に特定するためにできることは以下のとおりです。これはMinGWツールを使用している場合にも当てはまります。
1. Vimを"-g"オプション付きでコンパイルします（src/Makefileにこのための行があり、コメント解除できます）。また、"strip"が無効になっていることを確認してください（インストールしないか、"STRIP = /bin/true"の行を使用してください）。
2. 次のコマンドを実行します（"11"を失敗したテストに置き換えてください）
cd testdir
gdb ../vim
run -u unix.vim -U NONE -s dotest.in test11.in
3. Vimがクラッシュした場所を確認します。gdbがこのためのメッセージを表示するはずです。
4. 次のコマンドでgdbからスタックトレースを取得します
where
スタックトレースの別の場所は、次のようにチェックできます
frame 3
"3"をスタックトレースの番号の1つに置き換えます。
Vimがメモリリークしている疑いがあり、Linuxを使用している場合、valgrindツールはメモリリークを特定するのに非常に役立ちます。
まず、VimをEXITFREEを定義してビルドします。MAKEFILEでこれを探して、行のコメントを解除してください。
次のコマンドを使用してVimを起動します
valgrind --log-file=valgrind.log --leak-check=full ./vim
注: Vimの実行速度は大幅に低下します。vimrcが大きい場合や、複数のプラグインがある場合は、起動に時間がかかるか、"-u NONE"引数を付けて実行する必要があります。
getpwuid()やXtVaAppCreateShell()などのライブラリから発生するリークがしばしばあります。これらは避けられません。バイト数は非常に小さく、1Kバイト未満である必要があります。
Windows版のVimが再現可能な方法でクラッシュする場合、有益なバグレポートを提供するための手順をいくつか実行できます。
実行可能ファイルのデバッグシンボル（PDB）ファイルを取得する必要があります。gvim.exeの場合はgvim.pdb、vim.exeの場合はvim.pdbです。PDBは、実行可能ファイルを入手した場所と同じ場所から入手できるはずです。必ずEXEと一致するPDB（同じ日付）を使用してください。
Microsoft Visual C++コンパイラを使用して実行可能ファイルを自分でビルドした場合は、PDBがEXEとともにビルドされています。
Visual Studioをお持ちの場合は、VC ToolkitとWinDbgの代わりにそれを使用してください。
他のコンパイラについては、CygwinおよびMinGWコンパイラの場合は、対応するデバッガー（gdb（上記
debug-gccを参照））を常に使用する必要があります。
debug-vs2005
3.2 Visual Studio 2005/Visual C++ 2005 ExpressでのVimクラッシュのデバッグ
まず、vim.exeまたはgvim.exeを起動し、次にVisual Studioを起動します。（Visual Studioをお持ちでない場合は、
get-ms-debuggersの手順に従って、Visual C++ 2005 Express Editionの無料コピーを入手してください。）
[ツール]メニューの[プロセスにアタッチ]をクリックします。Vimプロセスを選択します。
Vimでクラッシュを再現します。Visual Studioで、Vimプロセスで未処理の例外が発生したことを知らせるダイアログが表示されます。[中断]をクリックして、プロセスを中断します。
Visual Studioで、シンボルがロードされておらず、ソースコードを表示できないことを知らせる別のダイアログが表示されます。[OK]をクリックします。
いくつかのウィンドウが開きます。[呼び出し履歴]ウィンドウを右クリックします。[シンボルのロード]を選択します。[シンボルの検索]ダイアログが開き、（g）vim.pdbを探します。PDBファイルがあるディレクトリに移動し、[開く]をクリックします。
この時点で、Vimの関数名と行番号を含む完全な呼び出し履歴が表示されるはずです。いずれかの行をダブルクリックすると、[ソースの検索]ダイアログが表示されます。Vimのソースがあるディレクトリに移動します（お持ちの場合）。
これ以上のデバッグ方法がわからない場合は、":help bug-report"の手順に従ってください。呼び出し履歴をバグレポートに貼り付けてください。
有償版のVisual Studioをお持ちの場合は、[デバッグ]メニューからミニダンプを保存し、バグレポートとともに送信できます。ミニダンプは、プロセスの状態に関する情報を含む小さなファイル（<100KB）です。Visual C++ 2005 Express Editionでは、ミニダンプを保存できず、ジャストインタイムデバッガーとしてインストールすることもできません。ミニダンプを保存する必要がある場合、またはジャストインタイム（ポストモーテム）デバッガーが必要な場合は、WinDbg（
debug-windbg）を使用してください。
Visual Studio IDEと同様に、WinDbgを実行中のVimプロセスにアタッチできます。また、システムでWinDbgをポストモーテムデバッガーとして自動的に起動させることもできます。WinDbgをポストモーテムデバッガーとして設定するには、"windbg -I"を実行します。
WinDbgを実行中のVimプロセスにアタッチするには、WinDbgを起動します。[ファイル]メニューの[プロセスにアタッチ]を選択します。Vimプロセスを選択して、[OK]をクリックします。
この時点で、[ファイル]メニューの[シンボルファイルのパス]を選択し、Vim PDBを含むフォルダーをsympathに追加します。Vimソースが使用可能な場合は、[ファイル]メニューの[ソースファイルのパス]を使用します。これで、WinDbgでソースファイルを開いて、必要に応じてブレークポイントを設定できます。クラッシュを再現します。WinDbgは、クラッシュした場所でソースファイルを開く必要があります。[表示]メニューを使用すると、呼び出し履歴、ローカル変数、ウォッチウィンドウなどを調べることができます。
WinDbgがポストモーテムデバッガーの場合、VimプロセスにWinDbgをアタッチする必要はありません。クラッシュを再現するだけで、WinDbgが自動的に起動します。上記と同様に、シンボルファイルのパスとソースファイルのパスを設定します。
ミニダンプを保存するには、WinDbgコマンドラインで次のように入力します
.dump vim.dmp
ミニダンプファイルがある場合は、Visual StudioまたはWinDbgで開くことができます。
Visual Studio 2005の場合：[ファイル]メニューの[開く]、[プロジェクト/ソリューション]を選択します。.dmpファイルに移動して開きます。次に、F5キーを押してデバッガーを起動します。
debug-vs2005の手順に従って、シンボルファイルのパスを設定します。
WinDbgの場合：[ファイル]メニューの[クラッシュダンプを開く]を選択します。
debug-windbgの手順に従って、シンボルファイルのパスを設定します。