vimspector
1.0.0
チュートリアルと使用法の概要については、Vimspector Web サイトをご覧ください。
.vimspector.json形式の詳細な説明については、リファレンス ガイドを参照してください。
このプラグインは、複数の言語に対応する有能な Vim グラフィカル デバッガーです。主に C++、Python、TCL についてテストされていますが、理論上は Visual Studio Code がサポートするあらゆる言語をサポートしています (ただし、注意事項を参照してください)。
Vimspector の Web サイトには、UI の概要と、構成とセットアップの基本的な手順が記載されています。
しかし今のところ、Vimspector が Vim をデバッグしている (かなり古い) スクリーンショットを以下に示します。
そして、いくつかの簡単なデモ:
<Plug>VimspectorBalloonEvalを参照)次の表に、「組み込み」の言語を (実行時の依存関係とともに) リストします。これらはサポートのレベルによって分類されています。
Tested : 完全にサポートされており、Vimspector 回帰テストでカバーされています。Supported : 完全にサポートされており、頻繁に使用され、手動でテストされていますExperimental : 機能していますが、頻繁には使用されず、テストされることもほとんどありませんLegacy : サポートされなくなりました。設定を移行してください。Retired : もう含まれていない、またはサポートされていません。| 言語 | 状態 | スイッチ ( install_gadget.py用) | アダプター ( :VimspectorInstall用) | 依存関係 |
|---|---|---|---|---|
| C、C++、Rust、Jai など。 | テスト済み | --allまたは--enable-c (または cpp) | vscode-cpptools | モノコア |
| C、C++、Rust、Jai など。 | テスト済み | --enable-rust 、 --enable-cなど。 | コードLLDB | なし |
| パイソン | テスト済み | --allまたは--enable-python | デバッグ | パイソン3 |
| 行く | テスト済み | --enable-go | 掘り下げる | ゴー 1.16+ |
| TCL | サポートされています | --allまたは--enable-tcl | tclプロ | TCL 8.5 |
| ボーン・シェル | サポートされています | --allまたは--enable-bash | vscode-bash-デバッグ | バッシュv?? |
| ルア | テスト済み | --allまたは--enable-lua | ローカル-lua-デバッガー-vscode | ノード >=12.13.0、Npm、Lua インタープリター |
| Node.js | サポートされています | --force-enable-node | vscode-js-デバッグ | ノード >= 18 |
| JavaScript | サポートされています | --force-enable-chrome | Chrome 用デバッガ | クロム |
| JavaScript | サポートされています | --force-enable-firefox | vscode-Firefox-デバッグ | Firefox |
| ジャワ | サポートされています | --force-enable-java | vscode-java-デバッグ | 互換性のある LSP プラグイン (後述) |
| PHP | 実験的 | --force-enable-php | vscode-php-デバッグ | ノード、PHP、XDEBUG |
| C# (ドットネット コア) | テスト済み | --force-enable-csharp | ネットコアデータベース | ドットネットコア |
| F#、VBなど | サポートされています | --force-enable-[fsharp,vbnet] | ネットコアデータベース | ドットネットコア |
| Go (レガシー) | 遺産 | --enable-go | vscode-go | ノード、ゴー、デルブ |
| パイソン2 | 遺産 | --force-enable-python2 | デバッグpy-python2 | Python 2.7 |
Vimspector は、Visual Studio Code で動作するすべてのデバッグ アダプタで動作するはずです。
「組み込み」ではない言語で Vimspector を使用するには、この Wiki ページを参照してください。
インストール方法は 2 つあります。
:help packages参照してください。packadd! vimspector .vimrcに追加.vimspector.jsonを作成するか、 g:vimspector_configurationsを設定します) - リファレンス ガイドを参照してください。依存関係を確認する
プラグイン マネージャーのドキュメントを参照し、プラグインをインストールします。Vundle の場合は、次を使用します。
Plugin ' puremourning/vimspector 'いくつかの「ガジェット」 (デバッグアダプター) をインストールします - インストールコマンドについてはここを参照し、インストールするガジェットを選択してください
プロジェクトのデバッグ プロファイルを構成します ( .vimspector.jsonを作成するか、 g:vimspector_configurationsを設定します) - リファレンス ガイドを参照してください。
以下のセクションでは、上記の簡単な概要を詳しく説明します。
Vimspector には次のものが必要です。
Linux のバージョンはどれですか? Ubuntu 20.04 以降と RHEL 7 でのみテストします。
neovim はマウス ホバー バルーンを実装していません。代わりに、 <Plug>VimspectorBalloonEvalマッピングがあります。これにはデフォルトのマッピングがないため、ポップアップで変数を表示するには次のようなものをお勧めします。
" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)
" for normal mode - the word under the cursor
nmap <Leader> di <Plug> VimspectorBalloonEval
" for visual mode, the visually selected text
xmap <Leader> di <Plug> VimspectorBalloonEval次の機能は Windows には実装されていません。
vim 構成を変更せずに vimspector を試してみたい場合は、 support/testに次のような多数の言語のサンプル プロジェクトがあります。
これらのいずれかをテストするには、cd でディレクトリに移動し、次を実行します。
vim -Nu /path/to/vimspector/tests/vimrc --cmd "let g:vimspector_enable_mappings='HUMAN'"
次に<F5>を押します。
また、 tests/testdata/cpp/simple/には、すべてが動作していることを確認するために使用できるMakefileを含む C++ プロジェクトもあります。これは CI の回帰テストで使用されるため、常に機能するはずであり、問題がバグではなく構成にあるかどうかを確認する良い方法です。
Vim プラグイン マネージャーは数多くありますが、特に優先するものを述べるつもりはありません。そのため、プラグイン マネージャーを使用する場合は、プラグイン マネージャーのドキュメントに従ってください。たとえば、Vundle の場合は次を使用します。
Plugin ' puremourning/vimspector 'プラグイン マネージャーをまだ使用していない場合は、次のようにこのリポジトリをパッケージ パスに複製して、vimspector を Vim パッケージとしてインストールします。
$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector
.vimrcで vimspector を構成します。 let g: vimspector_enable_mappings = ' HUMAN '.vimrcに追加することもできます。 packadd! vimspector
最小限の例については、 support/doc/example_vimrc.vimを参照してください。
Vimspector は、デバッグ アダプターの汎用クライアントです。デバッグ アダプター (「ガジェット」または「アダプター」と呼ばれる) は、実際のデバッガーと通信する作業を実際に実行します。
Vimspector を使用するには、いくつかのアダプターをインストールする必要があります。
これを行うにはいくつかの方法があります。
:VimspectorInstall <adapter> <args...>の使用 (オプションを表示するには TAB wildmenuを使用します。任意のinstall_gadget.pyオプションも受け入れます)python3 install_gadget.py <args>を使用する (すべてのオプションを表示するには--helpを使用します):VimspectorUpdateを使用して、サポートされている最新バージョンのガジェットをインストールします。以下は、インストールとアップグレードを実行するデモです。
install_gadget.pyと:VimspectorInstallどちらも同じ一連の処理を実行しますが、デフォルトの動作は若干異なります。サポートされている言語については、次のことが行われます。
gadgetDirシンボリックリンクを設定します。たとえば、ある言語のテスト済みデバッグ アダプターをインストールするには、次を実行します。
| インストールするには | スクリプト | 指示 |
|---|---|---|
<adapter> | :VimspectorInstall <adapter> | |
<adapter1> 、 <adapter2> 、 ... | :VimspectorInstall <adapter1> <adapter2> ... | |
<language> | ./install_gadget.py --enable-<language> ... | :VimspectorInstall --enable-<language> ... |
| サポートされているアダプター | ./install_gadget.py --all | :VimspectorInstall --all |
| アダプターはサポートされていますが、TCL はサポートされていません | ./install_gadget.py --all --disable-tcl | :VimspectorInstall --all --disable-tcl |
| サポートされているアダプターと試験的なアダプター | ./install_gadget.py --all --force-all | :VimspectorInstall --all |
| 特定のデバッグ構成用のアダプター | デバッグ開始時に Vimspector によって提案される |
:VimspectorInstallいくつかのオプションをデフォルトにして、バックグラウンドでinstall_gadget.pyを実行します。
:VimspectorUpdate install_gadget.py実行して、 .gadgets.jsonに既にインストールされているガジェットを再インストール (つまり、更新) します。
出力は最小限です。完全な出力を確認するには、 :VimspectorInstall --verbose ...または:VimspectorUpdate --verbose ...のようにコマンドに--verboseを追加します。
インストールが成功すると、出力ウィンドウは閉じられます (出力は永久に失われます)。 !開いたままにするには (例:VimspectorInstall! --verbose --allまたは:VimspectorUpdate! (など))。
たとえば、ソース管理から構成を再現できるように、インストールするガジェットが事前にわかっている場合は、 g:vimspector_install_gadgetsガジェットのリストに設定できます。これは次の場合に使用されます。
:VimspectorInstall引数なしで実行するか、:VimspectorUpdate例えば：
let g: vimspector_install_gadgets = [ ' debugpy ' , ' vscode-cpptools ' , ' CodeLLDB ' ]デフォルトでは、 install_gadget.pyインストールしたアダプターのセットで.gadgets.jsonを上書きしますが、 :VimspectorInstallはそれを更新し、新しく変更またはインストールされたアダプターのみを上書きします。
既存のアダプターを破棄せずに、スクリプトを使用して新しいアダプターのみを追加する場合は、次のように--update-gadget-configを追加します。
$ ./install_gadget.py --enable-tcl
$ ./install_gadget.py --enable-rust --update-gadget-config
$ ./install_gadget.py --enable-java --update-gadget-config vimspector リポジトリの外部でconfigurations維持したい場合 (カスタム ガジェットまたはグローバル構成がある場合に便利です)、別の basedir を使用するようにインストーラーに指示し、そのディレクトリを指すようにg:vimspector_base_dirを設定します。 :
$ ./install_gadget.py --basedir $HOME /.vim/vimspector-config --all --force-all次に、これを.vimrcに追加します。
let g: vimspector_base_dir = expand ( ' $HOME/.vim/vimspector-config ' ) :VimspectorInstallを使用する場合、 --basedirが手動で追加されない限り、 g:vimspector_base_dir設定が尊重されます (非推奨)。
さまざまなオプションの詳細については、 --helpを参照してください。
デバッグしたい言語が上記のサポート対象リストにない場合でも、おそらく動作させることはできますが、手間がかかります。
基本的に、デバッグ アダプターの動作するインストールを取得し、その起動方法を確認し、 .vimspector.json 、 .gadgets.json 、またはg:vimspector_adaptersのいずれかのadaptersエントリでそれを構成する必要があります。
実際の最も簡単な方法は、Visual Studio Code をインストールまたは起動し、その拡張機能マネージャーを使用して関連する拡張機能をインストールすることです。その後、 .vimspector.jsonのadaptersセクション、 gadgets.json 、またはg:vimspector_adaptersでアダプターを手動で構成できます。
PR は、サポートされる言語を追加することをいつでも歓迎します (これは、大まかに言うと、 python/vimspector/gadgets.py更新してテストすることになります)。
Vimspector はデフォルトで次のディレクトリを使用して.gadgets.jsonという名前のファイルを検索します: </path/to/vimspector>/gadgets/<os> 。
このパスは vimspector変数${gadgetDir}として公開されます。これは、ガジェットのコマンド ラインを構成する場合に便利です。
ここで、os は次のいずれかです。
macoslinuxwindows (ただし、Windows はサポートされていないことに注意してください)形式は.vimspector.jsonと同じですが、 adaptersキーのみが使用されます。
例：
{
"adapters" : {
"lldb-vscode" : {
"variables" : {
"LLVM" : {
"shell" : " brew --prefix llvm "
}
},
"attach" : {
"pidProperty" : " pid " ,
"pidSelect" : " ask "
},
"command" : [
" ${LLVM}/bin/lldb-vscode "
],
"env" : {
"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY" : " YES "
},
"name" : " lldb "
},
"vscode-cpptools" : {
"attach" : {
"pidProperty" : " processId " ,
"pidSelect" : " ask "
},
"command" : [
" ${gadgetDir}/vscode-cpptools/debugAdapters/bin/OpenDebugAD7 "
],
"name" : " cppdbg "
}
}
}ガジェット ファイルは、 install_gadget.py (または:VimspectorInstall ) によって自動的に書き込まれます。
Vimspector は</path/to/vimspector>/gadgets/<os>/.gadgets.d/*.jsonに一致するファイルも読み込みます。これらは.gadgets.jsonと同じ形式ですが、 install_gadget.pyの実行時に上書きされません。
Vimspector コードを更新した後 ( git pullまたはその他のパッケージ マネージャーを介して)、: :VimspectorUpdateを実行して、すでにインストールされているガジェットを更新します。
その動機は、Vim でのデバッグは、特に複数の言語を使用する場合、かなりひどい経験になるからです。 pyclewn がなくなり、組み込みの termdebug プラグインが gdb に限定されたため、オプションを検討したいと思いました。
言語サーバー プロトコルはよく知られていますが、デバッグ アダプター プロトコルはあまり知られていませんが、クライアントからデバッガーを抽象化する言語に依存しない API という同様の目標を達成します。
このプロジェクトの目的は、Visual Studio Code 用に構築されているデバッグ アダプターを活用して、Vim で複数の言語に対してシンプルかつ効果的なデバッグ エクスペリエンスを提供することです。
リモート デバッグを実行する機能は必須です。これは私のワークフローの鍵であるため、これをデバッグ エクスペリエンスに組み込むことがプロジェクトの最重要目標です。そのため、vimspector は、プログラムをリモートで実行し、プログラムにアタッチするための最上級のサポートを備えています。このサポートは vimspector に固有であり、実際のデバッグ アダプターでのそのようなサポートに加えて (補完的に) 行われます。
Vimspector は、デバッグ アダプター プロトコルの上にある vim UI です。これは高レベルであり、日常のデバッグ タスクに便利であることを目的としています。
Vimspector は次のようなものではありません。
Vimspector は開発中です。フィードバックや貢献は大歓迎です。
バックログは Trello で表示できます。
このプラグインは現在実験段階です。つまり、次のようなものを含め、そのどの部分も変更される可能性があります (そしておそらく変更されるでしょう)。
ただし、これは最も極端な場合にのみ実行し、そのような変更は十分前もって Gitter で発表することを約束します。何かが壊れるほど迷惑なものはありません。分かりました。
このプラグインの動機についての作者からのメッセージ:
多くの開発環境にはデバッガが組み込まれています。私は膨大な時間を Vim に費やしています。私はすべての開発を Vim で行っており、コードの構築やテストの実行などのワークフローもカスタマイズしました。
長年にわたって、私自身や友人や同僚があらゆる種類のファイルに
printf、puts、私は、インタラクティブでグラフィカルなデバッグ環境が、馴染みのないコードと馴染みのあるコードの両方を理解して推論するための最良の方法であると心から信じています。また、デバッガーへの簡単なアクセスが準備されていないことは、多くの人にとって隠れた生産性の大きな穴であると信じています。
誤解しないでください。グラフィカル デバッガーなしで開発を行う能力を備えた開発者が文字通り何百万人もいることは知っていますが、キーを押してデバッガーにジャンプする能力があれば、それは可能であると私は主張します。単なる脳のコード理解よりも速くて楽しいでしょう。
Vimspector を作成したのは、ツールを変更するのが面倒だからです。 C++ の場合は
gdb、Python の場合はpdbなど。それぞれに独自の構文があります。それぞれが独自の辞書です。それぞれに独自の欠点があります。私は、構成をソース管理にコミットできるように構成システムを設計し、同僚、友人、共同作業者、またはまったく知らない人に対しても機能するようにしました。
リモート デバッグを最上級の機能としたのは、それが私の仕事における主な使用例だからです。
Vimspector を使用すると、開発するすべての言語で
<F5>押すだけで、まったく同じワークフロー、マッピング、UI を使用してローカルまたはリモートでデバッグできます。これをVimspector のカーソルの下でボタンを押してテストを実行できるように、これを Vim に統合しました。この種の統合により、ワークフローと生産性が大幅に向上しました。新しいコードベースを学習するプロセスさえも楽しくなりました。- ベン・ジャクソン、クリエイター。
アパッチ2.0
著作権 © 2018 ベン・ジャクソン
Vimspector が好きすぎて、苦労して稼いだお金を手放したくない場合は、Vimspector の作者にとって意味のある次の慈善団体のいずれかに寄付することを検討してください (優先順)。
デフォルトでは、vimspector はマッピングを変更しません。マッピングは非常に個人的なものであるため、好みのものを見つけ出し、vim の強力なマッピング機能を使用して独自のマッピングを設定する必要があります。そのために、Vimspector は次の<Plug>マッピングを定義します。
| マッピング | 関数 | API |
|---|---|---|
<Plug>VimspectorContinue | デバッグ中は続行します。それ以外の場合はデバッグを開始します。 | vimspector#Continue() |
<Plug>VimspectorStop | デバッグを停止します。 | vimspector#Stop() |
<Plug>VimpectorRestart | 同じ構成でデバッグを再開します。 | vimspector#Restart() |
<Plug>VimspectorPause | デバッグ対象者を一時停止します。 | vimspector#Pause() |
<Plug>VimspectorBreakpoints | ブレークポイントウィンドウの表示/非表示を切り替える | vimspector#ListBreakpoints() |
<Plug>VimspectorToggleBreakpoint | 現在の行の行ブレークポイントを切り替えます。 | vimspector#ToggleBreakpoint() |
<Plug>VimspectorToggleConditionalBreakpoint | 現在の行の条件付き行ブレークポイントまたはログポイントを切り替えます。 | vimspector#ToggleBreakpoint( { trigger expr, hit count expr } ) |
<Plug>VimspectorAddFunctionBreakpoint | カーソル下の式に関数ブレークポイントを追加します | vimspector#AddFunctionBreakpoint( '<cexpr>' ) |
<Plug>VimspectorGoToCurrentLine | 現在のプログラムカウンターを現在の行にリセットします | vimspector#GoToCurrentLine() |
<Plug>VimspectorRunToCursor | カーソルまで実行 | vimspector#RunToCursor() |
<Plug>VimspectorStepOver | ステップオーバー | vimspector#StepOver() |
<Plug>VimspectorStepInto | ステップイン | vimspector#StepInto() |
<Plug>VimspectorStepOut | 現在の関数スコープから抜け出す | vimspector#StepOut() |
<Plug>VimspectorDisassemble | 分解を示します。命令ステッピングを有効にする | vimspector#ShowDisassembly() |
<Plug>VimspectorUpFrame | 現在の呼び出しスタック内で 1 フレーム上に移動します | vimspector#UpFrame() |
<Plug>VimspectorDownFrame | 現在の呼び出しスタック内のフレームを 1 つ下に移動します | vimspector#DownFrame() |
<Plug>VimspectorJumpToNextBreakpoint | カーソルを現在のファイル内の次のブレークポイントに移動します | vimspector#JumpToNextBreakpoint() |
<Plug>VimspectorJumpToPreviousBreakpoint | カーソルを現在のファイル内の前のブレークポイントに移動します | vimspector#JumpToPreviousBreakpoint() |
<Plug>VimspectorJumpToProgramCounter | カーソルを現在のフレームのプログラムカウンターに移動します | vimspector#JumpToProgramCounter() |
<Plug>VimspectorBalloonEval | ポップアップ内のカーソル (またはビジュアル) の下の式を評価します | 内部 |
これらは、以下の API 関数とほぼ 1 対 1 で対応しています。
たとえば、 <F5>デバッグを開始/継続したい場合は、これをvimrcなどの適切な場所に追加します (ヒント: run :e $MYVIMRC )。
nmap <F5> <Plug> VimspectorContinueさらに、多くのユーザーは、デバッグがアクティブな間、特定の Vimspector マッピングのみを有効にしたいと考えているでしょう。これも可能ですが、vimscipt を記述する必要があります。
とはいえ、多くの人は特定のデバッガーに精通しているため、 g:vimspector_enable_mappings指定された値に設定することで次のマッピングを有効にできます。
Visual Studio のようなマッピングを使用するには、 vimspector をロードする前に次のコードをvimrcに追加します。
let g: vimspector_enable_mappings = ' VISUAL_STUDIO '| 鍵 | マッピング | 関数 |
|---|---|---|
F5 | <Plug>VimspectorContinue | デバッグ中は続行します。それ以外の場合はデバッグを開始します。 |
Shift F5 | <Plug>VimspectorStop | デバッグを停止します。 |
Ctrl Shift F5 | <Plug>VimspectorRestart | 同じ構成でデバッグを再開します。 |
F6 | <Plug>VimspectorPause | デバッグ対象者を一時停止します。 |
F8 | <Plug>VimspectorJumpToNextBreakpoint | 現在のファイル内の次のブレークポイントにジャンプします。 |
Shift F8 | <Plug>VimspectorJumpToPreviousBreakpoint | 現在のファイル内の前のブレークポイントにジャンプします。 |
F9 | <Plug>VimspectorToggleBreakpoint | 現在の行の行ブレークポイントを切り替えます。 |
Shift F9 | <Plug>VimspectorAddFunctionBreakpoint | カーソル下の式に関数ブレークポイントを追加します |
F10 | <Plug>VimspectorStepOver | ステップオーバー |
Ctrl F10 | <Plug>VimspectorRunToCursor | カーソルまで実行* |
F11 | <Plug>VimspectorStepInto | ステップイン |
Shift F11 | <Plug>VimspectorStepOut | 現在の関数スコープから抜け出す |
Alt 8 | <Plug>VimspectorDisassemble | 分解を表示する |
注: Ctrl キーや F キーなどの一部のマッピングは、端末、キーボード、ウィンドウ システム、その他あらゆる種類のものによっては機能しない場合があります。 :help modifyOtherKeysおよびその他のソースを参照してください。これが機能しない場合は、「ヒューマン モード」マッピングを使用してください。
私のように、手が 2 本で指が 10 本しかない場合は、おそらく Ctrl-Shift-F キーが好きではないでしょう。また、ターミナルで実行している場合、特にTERMがscreen-256colorの場合、Shift-F キーに対して terminfo が間違っている可能性があります。これらの問題 (ハンドの数、 TERM変数) が修正できない場合は、 vimspector をロードする前に以下を追加して、次のマッピングを試してください。
let g: vimspector_enable_mappings = ' HUMAN '| 鍵 | マッピング | 関数 |
|---|---|---|
F5 | <Plug>VimspectorContinue | デバッグ中は続行します。それ以外の場合はデバッグを開始します。 |
F3 | <Plug>VimspectorStop | デバッグを停止します。 |
F4 | <Plug>VimspectorRestart | 同じ構成でデバッグを再開します。 |
F6 | <Plug>VimspectorPause | デバッグ対象者を一時停止します。 |
F9 | <Plug>VimspectorToggleBreakpoint | 現在の行の行ブレークポイントを切り替えます。 |
<leader>F9 | <Plug>VimspectorToggleConditionalBreakpoint | 現在の行の条件付き行ブレークポイントまたはログポイントを切り替えます。 |
F8 | <Plug>VimspectorAddFunctionBreakpoint | カーソル下の式に関数ブレークポイントを追加します |
<leader>F8 | <Plug>VimspectorRunToCursor | カーソルまで実行 |
F10 | <Plug>VimspectorStepOver | ステップオーバー |
F11 | <Plug>VimspectorStepInto | ステップイン |
F12 | <Plug>VimspectorStepOut | 現在の関数スコープから抜け出す |
さらに、通常モードとビジュアル モードで<Plug>VimspectorBalloonEvalにマッピングを追加することをお勧めします。次に例を示します。
" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)
" for normal mode - the word under the cursor
nmap <Leader> di <Plug> VimspectorBalloonEval
" for visual mode, the visually selected text
xmap <Leader> di <Plug> VimspectorBalloonEvalまた、スタックを上下に移動したり、ブレークポイント ウィンドウを切り替えたり、逆アセンブリを表示したりするためのマッピングを追加することもできます。
nmap <LocalLeader> <F11> <Plug> VimspectorUpFrame
nmap <LocalLeader> <F12> <Plug> VimspectorDownFrame
nmap <LocalLeader> B <Plug> VimspectorBreakpoints
nmap <LocalLeader> D <Plug> VimspectorDisassembleこのセクションでは、機能別に整理された詳細な使用手順を定義します。ほとんどのユーザーにとって、マッピング セクションには最も一般的なコマンドとデフォルトの使用法が含まれています。このセクションは、独自のマッピングやカスタム動作を作成するための参照として使用できます。
以下のすべての手順は、単一のデバッグ セッションを前提としています。複数の独立したアプリを同時にデバッグする方法の詳細については、[複数のデバッグ セッション][#multiple-debugging-sessions] を参照してください。
.vimspector.jsonを作成します。以下を参照してください。:call vimspector#Launch() 、構成を選択します。新しいセッションを起動すると、それがアクティブな [デバッグ セッション][#multiple-debugging-sessions] になります。
デバッグ アダプター構成でpidProperty使用し、 attachリクエストを行う場合は、アタッチ先の PID (プロセス ID) を入力するように求められます。
これを簡単にするために、Vimspector は PID をリストするための小さなユーティリティを提供します。これは非常にシンプルなpsのクローンのようなものですが、サポートされているすべてのプラットフォームで動作します。設定手順については、README を参照してください。
support/vimspector_process_listディレクトリでgo build実行して設定します。
Vimspector がこのアプリを見つけることができた場合、デフォルトで現在のユーザーが所有するすべてのプロセスをリストしようとします。
あるいは (できれば) ${PickProcess("binaryName")}と呼ばれる特別な形式の変数展開を使用することもできます。この呼び出しのバージョンにより、このバイナリ名に一致する現在のユーザーのすべてのプロセスがリストされます。
例えば：
"Attach" : {
"adapter" : "CodeLLDB" ,
"configuration" : {
"request" : "attach" ,
"program" : "${workspaceRoot}/Jails" ,
"pid" : "${PickProcess("jails")}"
}
}これにより、一致する各プロセス、その親プロセス、開始時刻、作業ディレクトリがリストされます。それは次のようになります:
PID PPID CWD START
52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24
Enter Process ID:
次に、PID を入力して<CR>を押します。
プロセス ピッカーを独自の関数に置き換えることもできます。何らかの関数を定義し、 g:vimspector_custom_process_picker_funcをその関数の名前に設定するとします。 PickProcess拡張関数に渡される引数がすべて渡されます。また、 pidPropertyが指定されるたびに使用されるため、引数も処理しなければなりません ( ...関数の仮引数として使用します。 :help ...参照)。
たとえば、 fzf提供されたvimspector_process_listとともに使用するには、次のようにします。
function ! CustomPickProcess ( ... ) abort
let ps = $HOME .. ' /.vim/bundle/vimspector/support/vimspector_process_list/vimspector_process_list '
" a:0 is number of args
" a:1 is the optional binary name
if a: 0 > 0
let ps .= ' ^ ' . a: 1 . ' $ '
endif
let line_selected = fzf#run ( {
' source ' : ps ,
' options ' : ' --header-lines=1 '
. ' --prompt="Select Process: " '
,
} )[ 0 ]
if empty ( line_selected)
return 0
endif
let pid = split ( line_selected )[ 0 ]
return str2nr ( pid )
endfunction
let g: vimspector_custom_process_picker_func = ' CustomPickProcess 'または、 psの出力でfzf使用するには:
function ! CustomPickProcess ( ... ) abort
let ps = ' ps aux '
let line_selected = fzf#run ( {
' source ' : ps ,
' options ' : ' --header-lines=1 '
. ' --prompt="Select Process: " '
,
} )[ 0 ]
if empty ( line_selected)
return 0
endif
let pid = split ( line_selected )[ 0 ]
return str2nr ( pid )
endfunction
let g: vimspector_custom_process_picker_func = ' CustomPickProcess '特定のデバッグ構成を起動するか、起動用の置換変数を指定するには、以下を使用できます。
:call vimspector#LaunchWithSettings( dict )引数は次のキーを持つdictです。
configuration : (オプション) 起動するデバッグ構成の名前<anything else> : (オプション) 設定する変数の名前これにより、ある程度の統合と自動化が可能になります。たとえば、 ${Test}という名前の置換変数を含むRun Testという名前の構成がある場合、最終的に実行されるマッピングを作成できます。
vimspector#LaunchWithSettings ( #{ configuration: ' Run Test '
Test: ' Name of the test ' } )これにより、 ${Test} 'Name of the test'に設定してRun Test構成が開始され、Vimspector はユーザーにこれらの入力や確認を求めるプロンプトを表示しません。
Java デバッガーに接続するポートを指定するために使用できる別の例については、YouCompleteMe 統合ガイドを参照してください。
アドホック構成で起動するには、次を使用できます。
call vimspector#LaunchWithConfigurations( dict )引数は .vimspector ファイルのconfigurationsセクションであるdictです。 1 つの構成を渡すと、それが実行する構成として選択されます。例えば：
let pid = <some_expression>
call vimspector#LaunchWithConfigurations ({
" attach " : {
" adapter " : " netcoredbg " ,
" configuration " : {
" request " : " attach " ,
" processId " : pid
}
}
} )これにより、ディスク上にローカルの .vimspector ファイルが必要なく、デバッガーが起動され、指定されたプロセスにアタッチされます。 ${workspaceRoot}変数は、vim で現在開いているファイルの親フォルダーを指します。
Vimspector は次のロジックを使用して、起動する構成を選択します。
autoselect falseに設定されていない場合は、それを使用します。default trueに設定され、 autoselect falseに設定されていない構成が 1 つだけ存在する場合は、それを使用します。詳細についてはリファレンスガイドを参照してください。
vimspector#GetConfigurations()を使用して、現在のバッファーのファイルタイプの構成のリストを取得します。たとえば、構成の配列を取得し、結果のあいまい一致を取得するには
: call matchfuzzy ( vimspector#GetConfigurations (), " test::case_1 " )ブレークポイントを操作するためのデフォルトのマッピングについては、マッピングのセクションを参照してください。このセクションでは、vimscript 関数の完全な API について説明します。
ブレークポイントは、現在の [デバッグ セッション][#multiple-debugging-sessions] に関連付けられます。セッション間を切り替えると、前のセッションのブレークポント標識が削除され、新しくアクティブ化されたセッションのブレークポイントが表示されます。すべてのセッションのブレークポイントを確認すると便利かもしれませんが、非常に混乱する可能性があります。
:VimspectorBreakpointsを使用するか、何かを<Plug>VimspectorBreakpointsにマップして、ブレークポイント ビューを開きます。ここから、ブレークポイントの一覧表示、削除へのジャンプ、追加、切り替えを行うことができます。
ブレークポイント ウィンドウを切り替えるには、次のようなマッピングをお勧めします。
nmap <Leader> db <Plug> VimspectorBreakpoints次のマッピングは、ブレークポイント ウィンドウにデフォルトで適用されます。
t , <F9> - 切り替え、つまりブレークポイントの有効化/無効化T - トグル、つまりすべてのブレークポイントを有効/無効にしますdd , <Del> - 現在のブレークポイントを削除しますcc 、 C - 現在のブレークポイント オプションを編集しますi 、 a 、 o - 新しい行ブレークポイントを追加しますI 、 A 、 O - 新しい関数ブレークポイントを追加します<Enter>またはダブルクリック - 行ブレークポイントにジャンプしますWinBar も (サポートされている場合) 提供されます。これにより、セッションの保存/復元、すべてのブレークポイントのクリア、例外ブレークポイント オプションのリセットなどの機能が追加されます。
最も単純で最も一般的なブレークポイントの形式は、行ブレークポイントです。指定した行が実行されると、実行が一時停止されます。
ほとんどのデバッグ シナリオでは、ユーザーは<F9>押して現在の行に行ブレークポイントを作成し、 <F5>押してアプリケーションを起動します。
一部のデバッグ アダプターは条件付きブレークポイントをサポートしています。 vimspector は、デバッガーが条件付きブレークポイントを (まだ) サポートしていないかどうかを通知しないことに注意してください。条件付きブレークポイントは、何らかの式が true と評価されるか、他の制約が満たされる場合にのみトリガーされるブレークポイントです。
上記の関数の一部は、オプションの辞書である単一のオプションの引数を取ります。辞書には次のキーを含めることができます。
condition : ブレークポイントを起動するかどうかを決定するために評価されるオプションの式。すべてのデバッグ アダプターでサポートされているわけではありません。たとえば、 abcが10ときにブレークするには、言語に応じてabc == 10のように入力します。hitCondition : ブレークポイントを無視する回数を決定するために評価されるオプションの式。 (おそらく?) conditionと組み合わせて使用すべきではありません。すべてのデバッグ アダプターでサポートされているわけではありません。たとえば、この行に 3 回目に到達してブレークするには、 3と入力します。logMessage : このブレークポイントを代わりに「ログポイント」にするためのオプションの文字列。トリガーされると、このメッセージは実行を中断するのではなく、コンソールに出力されます。中括弧内に式を埋め込むことができます{like this} 、たとえば#{ logMessage: "Iteration {i} or {num_entries / 2}" }いずれの場合も、式はデバッガによって評価されるため、式を評価するときにデバッガが理解できる方言を使用する必要があります。
<leader><F9>マッピングを使用する場合、ユーザーはコマンド ラインにこれらの式を入力するよう求められます (履歴付き)。
例外ブレークポイントは通常、例外がスローされたとき、またはその他のエラー状態が発生したときに起動されます。デバッガによっては、デバッグを開始するときに、例外の処理方法についていくつかの質問が表示される場合があります。これらは「例外ブレークポイント」であり、vimspector は Vim の実行中に選択を記憶します。
ほとんどのデバッグ アダプタのデフォルトは正常であるため、通常はデフォルトを受け入れることができます ( <CR> ! を押し続けるだけです)。ただし、続行したい場合は、「キャッチさuncaught exception 」と言ってから、それにYと答えます (たとえば)。
.vimspector.jsonで選択内容を構成できます。詳細については、構成ガイドを参照してください。
注:以前は、ToggleBreakpoint は 3 つの状態 (有効、無効、削除) を循環していました。多くのユーザーは、「無効」状態がほとんど役に立たないことに気づいたため、動作が変更されました。 ToggleBreakpoint は常にブレークポイントを作成または削除します。ブレークポイントを「無効」にしたい場合は、ブレークポイント ウィンドウを使用し、そこから「切り替え」( t )ます。
vimspector#ToggleBreakpoint( { options dict } )使用して行ブレークポイントを設定/削除します。引数はオプションです (下記を参照)。vimspector#AddFunctionBreakpoint( '<name>', { options dict} )を使用して関数ブレークポイントを追加します。 2 番目の引数はオプションです (以下を参照)。vimspector#SetLineBreakpoint( file_name, line_num, { options dict } )を使用して、特定のファイル/行にブレークポイントを設定します。最後の引数はオプションです (下記を参照)。vimspector#ClearLineBreakpoint( file_name, line_num )を使用して、特定のファイル/行のブレークポイントを削除しますvimspector#ClearBreakpoints()を使用してすべてのブレークポイントをクリアしますvimspector#ResetExceptionBreakpoints()使用して例外ブレークポイント構成をクリアし、「C++ スロー時のブレーク」などのさまざまな質問に再回答します。:VimspectorMkSessionおよび:VimspectorLoadSessionを使用してブレークポイントを保存および復元するcall vimspector#ListBreakpoints() - ブレークポイント ウィンドウを切り替えるcall vimspector#BreakpointsAsQuickFix() - 現在のブレークポイントのセットを vim クイックフィックス形式で返します例:
call vimspector#ToggleBreakpoint() - 現在の行のブレークポイントを切り替えますcall vimspector#SetLineBreakpoint( 'some_file.py', 10 ) - some_filepy:10にブレークポイントを設定しますcall vimspector#AddFunctionBreakpoint( 'main' ) - main関数に関数ブレークポイントを追加しますcall vimspector#ToggleBreakpoint( { 'condition': 'i > 5' } ) - i > 5がtrue場合にのみトリガーされるブレークポイントを現在の行に追加しますcall vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i > 5' } ) - i > 5がtrue場合にのみトリガーされるブレークポイントをsome_file.py:10に追加しますcall vimspector#ClearLineBreakpoint( 'some_file.py', 10 ) - some_file.py:10のブレークポイントを削除しますcall vimspector#ClearBreakpoints() - すべてのブレークポイントをクリアするVimspectorMkSession - .vimspector.sessionを作成するVimspectorLoadSession - .vimspector.sessionを読み取りますVimspectorMkSession my_session_file - my_session_file作成するVimspectorLoadSession my_session_file - my_session_file読み取り注: 実験的な機能であり、ユーザーのフィードバックに基づいて将来大幅に変更される可能性があります。
コード ウィンドウで行ブレークポイントを追加するのと同じ方法で、逆アセンブリ ウィンドウから命令ブレークポイントを追加できます。同じマッピングと関数がそれらの追加と切り替えに機能します。デバッグ アダプターでサポートされている場合は、この方法でログポイントや条件付きブレークポイントを作成することもできます。
現在、命令ブレークポイントは、分解を含むバッファーに対するラインブレークポイントとして内部的にモデル化されていますが、それは将来的に変化する可能性があるため、これに依存しないでください。
命令ブレークポイントも表示され、ブレークポイントウィンドウから削除/無効にすることができます。
現在、デバッグセッションが終了すると、命令ブレークポイントが自動的にクリアされます。この理由は、アドレスが他のデバッグセッションで有効であることを保証できないためです。ただし、これは将来も変化する可能性があります。
vimspector#ClearBreakpoints()を使用して、例外ブレークポイントの選択のメモリを含むすべてのブレークポイントをクリアします。
vimspector#RunToCursorまたは<leader><F8>を使用：これにより、現在のラインに一時的なブレークポイントが作成され、実行を続け、ヒット時にブレークポイントをクリアします。
vimspector#GoToCurrentLine()または<Plug>VimspectorGoToCurrentLineへのマッピングを使用して、現在の実行を現在オンにしているラインにジャンプします。
サポートされている場合、これはコードのセクションを再実行したり、完全にスキップしたりするのに役立ちます。
現在の行に複数の「ターゲット」がある場合、1つを選択するように求められます。
Vimspectorは、ブレークポイント（およびその他のもの）をセッションファイルに保存および復元できます。そのために次のコマンドが存在します。
VimspectorMkSession [file/dir name] - 最新のブレークポイント、ログポイント、条件付きブレークポイント、関数ブレークポイント、および供給されたディレクトリのデフォルトファイルへの例外ブレークポイントフィルターを保存します。VimspectorLoadSession [file/dir name] - 提供されたセッションファイルまたは提供されたディレクトリのデフォルトファイルからブレークポイントを読み取り、現在設定されているブレークポイントを置き換えます。ロードする前に、すべての現在のブレークポイントがクリアされます（まるでvimspector#ClearLineBreakpoints()が呼び出されたかのように）。どちらの場合も、ファイル/dir名引数はオプションです。デフォルトでは、ファイルは.vimspector.sessionという名前ですが、これはg:vimspector_session_file_nameを他の何かに設定するか、コマンドを呼び出すときにパスを手動で指定することでグローバルに変更できます。ディレクトリを提供すると、デフォルトまたは構成されたセッションファイル名がfronに読み取られるか、そのディレクトリに書き込まれます。 Othewise、ファイルは現在開いているバッファに基づいて読み取られるか、現在の作業ディレクトリに書き込まれます。
高度なユーザーは、たとえば、 VimEnterやVimLeaveオートコマンドを追加することにより、ロードと保存のプロセスを自動化することをお勧めします。その場合、 silent!ファイルを読み取ったり書いたりできない場合は、迷惑なエラーを避けます。
自動化の最も単純な形式は、セッションファイルでVIMを開始するたびにVimspectorセッションをロードすることです。これはこれを行うのと同じくらい簡単です：
$ echo silent VimspectorLoadSession > Sessionx.vim
参照:help mksession *x.vimファイルの詳細については、ヘルプMksession。また、 SessionLoadPost ：を使用してこのようなことを行うこともできます。
autocmd SessionLoadPost * silent ! VimspectorLoadSessionvimspector#StepInto()などです。vimspector vimspector#StepSOver()およびvimspector#StepIOver()なども、それぞれ声明と命令の粒度のバリアントです。 <CR>使用するか、左マウスでダブルクリックして展開/崩壊します（+、 - ）。<C-CR> （control + <CR> ）または<leader><CR>で設定します（ modifyOtherKeys機能しない場合）スコープと変数は、buffer vimspector.Variablesによって表されます。
変数と時計にもっと冗長なディスプレイを好む場合は、 let g:vimspector_variables_display_mode = 'full'ができます。デフォルトでは、名前と値のみが表示され、他のデータがマウスをホバリングしたり、変数（または時計）ウィンドウに値を含むラインに<Plug>VimspectorBalloonEvalをトリガーしたりして利用できます。
Variables and scopesのすべてのルールが適用されます。
a + b ）を実行し、その結果を取得します。nmap ）とビジュアルモード（ xmap ）マッピングを<Plug>VimspectorBalloonEvalに作成して、ポップアップを手動でトリガーします。<C-CR> （control + <CR> ）または<leader><CR>で設定します（ modifyOtherKeys機能しない場合）j 、 k ）を使用します。 <Esc> （またはツールチップウィンドウを離れて）ツールチップを閉じます。デバッグセッションを開始する前に、設定g:vimspector_enable_auto_hover=0で自動ホバリングポップアップを無効にできます。その後、何かを<Plug>VimspectorBalloonEvalにマッピングして、手動でトリガーできます。
ウォッチウィンドウは、変数と式を検査するために使用されます。式は、選択したスタックフレームで「フォーカス」されています。
Watchesウィンドウはプロンプトバッファで、利用可能です。挿入モードを入力して、新しい時計式を追加します。
<CR>でコミットします。:VimspectorWatch <expression> 。いくつかのデバッグアダプターでは、式のタブ完了が利用可能です。<CR>で結果を展開するか、左マウスでダブルクリックします。<C-CR> （control + <CR> ）または<leader><CR>で設定します（ modifyOtherKeys機能しない場合）<DEL>で削除します。時計は、buffer vimspector.Watchesによって表されます。
変数と時計にもっと冗長なディスプレイを好む場合は、 let g:vimspector_variables_display_mode = 'full'ができます。デフォルトでは、名前と値のみが表示され、他のデータがマウスをホバリングしたり、変数（または時計）ウィンドウに値を含むラインに<Plug>VimspectorBalloonEvalをトリガーしたりして利用できます。
デバッグセッションを開始する前に、設定g:vimspector_enable_auto_hover=0で自動ホバリングポップアップを無効にできます。その後、何かを<Plug>VimspectorBalloonEvalにマッピングして、手動でトリガーできます。
時計プロンプトバッファーには、現在の式の完了を計算する関数にomnifuncが設定されています。これは、 <Ctrl-x><Ctrl-o>で些細なことに使用されています（参照:help ins-completion ）、またはお気に入りの完了システムと統合されています。バッファ内のFiletypeはVimspectorPromptに設定されています。
youcompletemeの場合、次の構成はうまく機能します。
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}:VimspectorDisassemble 、 vimspector#ShowDisassembly()または<Plug>VimspectorDisassemble一部のデバッグアダプター（少数！）は、分解をサポートしています。これがDAPで機能する方法は少し奇妙ですが、実際には、Vimspectorは現在のStack FrameのPCの周りの多くの指示を分解するように求めます。これは、コードウィンドウと同様のウィンバーを備えたウィンドウに表示されますが、指示が粒度を踏んでいます。現在の命令のサインがあり、構文の高さはデフォルトで「ASM」になり、X86とARMではほとんど問題があります。
上記のように、現在のウィンドウが分解ウィンドウであり、デフォルトの「ステップ」コマンド（eg <F10> ）を使用する場合、ステッピングはステートメントごとではなく、自動的にインストラクションに合わせてchnされます。
プロセスが停止するたびに、Vimspectorは現在のPCの周りの指示でいっぱいの約2つのウィンドウを要求します。詳細を確認するには、ウィンドウをスクロールできます。 Vimspectorは、窓が上部または下部の近くにスクロールすると、追加の命令でページを追加します。これは完璧ではありません。ページを作成するには、もう少しスクロールする必要がある場合があります（上部のCtrl-e Ctrl-yなど）。これは理想的ではなく、将来改善される可能性があります。
let g:vimspector_disassembly_height = 10 （または何回の行）を使用して、分解ウィンドウのintial heightを制御できます。
分解ウィンドウのバッファーのFiletype（および構文）はvimspector-disassemblyです。 FileType AutoCommandsを使用して、構文の強調表示などをカスタマイズできます。
注：この機能は実験的であり、ユーザーのフィードバックに基づいて何らかの形で変更される場合があります。
一部のデバッグアダプターは、変数に関連付けられたプロセスメモリをダンプする方法を提供します。これは、次のような変数や監視Windowsから実行できます。
<leader>mマッピング（デフォルトでは、カスタマイズできます）vimspector#ReadMemory()関数これを行うと、いくつかのバイトを入力して（現在のカーソルラインに関連付けられた場所から）、その場所からのオフセットを読み取るように求められます。 xxdの出力と同様に、HEXとASCIIのメモリダンプを含むコードウィンドウに新しいバッファーが表示されます。
注：この機能は実験的であり、ユーザーのフィードバックに基づいて何らかの形で変更される場合があります。
スタックトレースウィンドウは、各プログラムスレッドの状態を示しています。停止したスレッドは、そのスレッドのスタックトレースを表示するために拡張できます。
多くの場合、常にではありませんが、ブレークポイントがヒットしたときにすべてのスレッドが停止されます。スレッドのステータスは、スレッドの名前の後に括弧内に表示されます。基礎となるデバッガーによってサポートされている場合、スレッドは一時停止し、スタックトレースウィンドウ内から個別に継続できます。
CursorLine Highlightグループで強調表示されている特定のスレッドは、「フォーカスされた」スレッドです。これは、コードウィンドウで「ステップイン」、「ステップアウト」、「続行」、「一時停止」などのコマンドを受信するスレッドです。フォーカスされたスレッドは、そのスレッドに「切り替える」ように手動で変更できます。
<CR>を使用するか、左マウスでダブルクリックしてスレッドスタックトレースを展開/崩壊させるか、ウィンバーボタンを使用します。<CR>使用するか、スタックフレームに左マウスでダブルクリックしてジャンプします。vimspector#PauseContinueThread()を使用して、選択したスレッドを個別に一時停止または続行します。<leader><CR> 、またはvimspector#SetCurrentThread()を使用して、現在選択されているスレッドに「フォーカスされた」スレッドを設定します。選択した行がスタックフレームの場合、そのフレームのスレッドにフォーカスされたスレッドを設定し、コードウィンドウでそのフレームにジャンプします。スタックトレースは、buffer vimspector.StackTraceで表されます。
Debugeeが子プロセスを開始し、デバッグアダプターがマルチセッションデバッグをサポートする場所など、子供のデバッグセッションがある場合、各セッションのスレッドは個別に表示されます。現在アクティブなセッションは、現在アクティブなスレッド/スタックフレームとして強調されているセッションです。制御を別のセッションに切り替えるには、そのセッション内のスレッドに焦点を合わせます。
注：これは、既存のセッションの子供として作成されたセッションを指し、[複数の（親）デバッグセッション] [＃複数の突入セッション]と混同しないでください。
:VimspectorShowOutput <category> 。コマンドライン完了を使用して、カテゴリを確認します。出力ウィンドウが閉じている場合、新しいものを開くことができます:VimspectorShowOutput <category> （タブの完了 - wildmenuを使用してオプションを確認します）。
コンソールウィンドウは、利用可能なプロンプトバッファーであり、デバッグアダプターのインタラクティブCLIとして使用できます。これのサポートは、アダプターによって異なります。
:VimspectorEval <expression> 。いくつかのデバッグアダプターで完了を利用できます。<CR>でリクエストをコミットします注：上記の時計も参照してください。
出力ウィンドウが閉じている場合、新しいものを開くことができます:VimspectorShowOutput Console 。
コンソールプロンプトバッファには、現在のコマンド/式の完了を計算する関数にomnifuncセットが設定されています。これは、 <Ctrl-x><Ctrl-o>で些細なことに使用されています（参照:help ins-completion ）、またはお気に入りの完了システムと統合されています。バッファ内のFiletypeはVimspectorPromptに設定されています。
youcompletemeの場合、次の構成はうまく機能します。
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}Vimspectorログファイルには、VimspectorとDebugアダプターの間の通信の完全なトレースが含まれています。これは、VIMトレースバックではない何かがうまくいかない場合の診断情報の主要なソースです。
vimspectorログファイルを表示したい場合は、次のものを使用します:VimspectorToggleLogは、小さなウィンドウでテールします（Windowsで動作しません）。
:VimspectorDebugInfoでデバッグ情報をご覧ください
デバッガーを閉じるには、使用してください。
Reset:VimspectorReset 。call vimspector#Reset()停止またはリセット時にデバッグギーがまだ実行されている場合、いくつかのデバッグアダプターを使用すると、デバッグを終了するときに何が起こるべきかを指定できます。通常、デフォルトの動作は賢明であり、これがほとんどの場合に起こることです。これらは、DAPに応じたデフォルトです。
一部のデバッグアダプターを使用すると、切断時に何をすべきかを選択できます。この動作を制御する場合は、次のように使用するか、 :VimspectorResetまたはvimspector#Reset( { 'interactive': v:true } )に電話してください。デバッグアダプターがデバッグジーを終了するかどうかを選択できる場合、選択するように求められます。同じことがVimspector vimspector#Stop( { 'interactive': v:true } ) vimspector#Stop()にも当てはまります。
注：この機能は実験的であり、その一部はユーザーのフィードバックに応じて変更される場合があります。
Vimspectorは、任意の数のデバッグセッションを開始することをサポートしています。各セッションは、個々のUIタブに関連付けられています。通常、単一のアプリのみをデバッグするため、これについて考える必要はありませんが、この高度な機能は、複数の独立したアプリケーション、またはアプリケーションの複数の独立したインスタンスを同時にデバッグする必要がある場合に役立ちます。
いつでも、単一の「アクティブ」ルートセッションがあります。ブレークポイントは現在のセッションに関連付けられており、すべてのUIおよびAPIコマンドは現在アクティブなセッションに適用されます。
ルートセッションを切り替えると、前のセッションのブレークポントサインが削除され、新しくアクティブ化されたセッションのブレークポイントが表示されます。すべてのセッションでブレークポイントを見ると便利かもしれませんが、これは非常に混乱する可能性があります。
典型的なワークフローは次のとおりです。
:edit server.ccて<F5> ）。これは、選択された構成にちなんで名付けられたデバッグセッションを開始します。名前を変更できます:VimspectorRenameSession server 。:tabedit client.cc ）clientに名前を付けます:VimspectorNewSession client （ clientがアクティブセッションになりました）。clientセッションにブレークポイントを追加し、 <F5>でデバッグを開始します。これで、2つのvimspectorタブができました。直感的には、特定のタブにwwitchすることで、セッションがアクティブになります。アクティブセッションを手動で切り替えることもできます:VimspectorSwitchToSession <name> 。
要約すると、次の施設があります。
VimspectorNewSession <name>これにより、新しいセッションが作成され、アクティブになります。オプションの名前は、起動を開始するときに生成されたものの代わりに使用されます。VimspectorSwitchToSession <tab complete>を使用して手動で切り替える。VimspectorRenameSession <new name>VimspectorDestroySession <name>を使用して手動でそれらを破壊することができます（勇敢な場合）。ランニング/アクティブセッションを破壊することはできません。vimspector#GetSessionName()ステータスラインを入力するのに役立ちます。また、技術者向けのvimspector#GetSessionID()もあります。現在のセッション名をstatuslineに表示する方法の例を次に示します（ :help statusline 、またはファンシーステータスラインプラグインのドキュメントを参照）。
function ! StlVimspectorSession ()
" Only include in buffers containing actual files
if ! empty ( & buftype )
return ' '
endif
" Abort if vimspector not loaded
if ! exists ( ' *vimspector#GetSessionName ' ) ||
! exists ( ' *vimspector#GetSessionID ' )
return ' '
endif
return vimspector#GetSessionName ()
.. ' ( '
.. vimspector#GetSessionID ()
.. ' ) '
endfunction
" ... existing statusline stuff
" set statusline=...
" Show the vimspector active session name (max 20 chars) if there is onw.
set statusline += % ( % . 20 { StlVimspectorSession ()} % ).vimspector.jsonの構成の紹介については、Vimspector Webサイトの開始セクションをご覧ください。
変数、代替、例外ブレークポイントを指定する方法などの完全な説明については、ドキュメントを参照してください。
JSON構成ファイルは、Cスタイルのコメントを許可します。
// comment to end of line .../* inline comment ... */現在、次のデバッグアダプターでテストされています。
例.vimspector.json （ vscode-cpptoolsとlldb-vscodeの両方で動作します。LLDB lldb-vscodeの場合、アダプターの名前をlldb-vscodeに置き換えます。
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
"args" : [ ... ],
"cwd" : " <working directory> " ,
"environment" : [ ... ],
"externalConsole" : true ,
"MIMode" : " <lldb or gdb> "
}
},
"Attach" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " attach " ,
"program" : " <path to binary> " ,
"MIMode" : " <lldb or gdb> "
}
}
// ...
}
} Windowsユーザー向けのメモ： gdb.exeインストールする必要があります。 scoop install gdb使用することをお勧めします。 Vimspectorは、ライセンスのためにVisual Studioデバッガーを使用できません。
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
"stopAtEntry" : true
}
}
}
}バックエンドに応じて、複雑なタイプのきれいな印刷を手動で有効にする必要があります。
LLDB：デフォルトではかなり印刷が有効です
GDB：GDBプリティプリンターを有効にするには、以下のスニペットを検討してください。 .gdbinitでset print pretty onだけでは十分ではありません！
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
// ...
"MIMode" : " gdb " ,
"setupCommands" : [
{
"description" : " Enable pretty-printing for gdb " ,
"text" : " -enable-pretty-printing " ,
"ignoreFailures" : true
}
]
}
}
}
}CPPToolsのドキュメントでは、 miDebuggerAddress使用してCppToolsをGDBServerに接続する方法について説明します。これを行うときは、 "request": "attach"使用する必要があることに注意してください。
派手な場合は、Vimspectorをリモートで起動して添付させる例については、参照ガイドをご覧ください。
CodellDBは、少なくともMacOSでさまざまな方法でVSCODE-CPPTOOLSよりも優れています。
さびを参照してください。
別の方法は、LLVMに付属するlldb-vscode使用することです。その方法は次のとおりです。
brew install llvm ）/path/to/vimspector/gadgets/macos/.gadgets.d/lldb-vscode.json macos/.gadgets.d/lldb-vscode.json：negime naved negimingファイル： {
"adapters" : {
"lldb-vscode" : {
"variables" : {
"LLVM" : {
"shell" : " brew --prefix llvm "
}
},
"attach" : {
"pidProperty" : " pid " ,
"pidSelect" : " ask "
},
"command" : [
" ${LLVM}/bin/lldb-vscode "
],
"env" : {
"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY" : " YES "
},
"name" : " lldb "
}
}
}錆は、GDB/LLDBベースのデバッガーでサポートされています。したがって、上記のvscode-cpptoolsとlldb-vscodeで正常に動作します。ただし、RustのサポートはCodeLLDBで最適です。
./install_gadget.py --enable-rustまたは:VimspectorInstall CodeLLDBsupport/test/rust/vimspector_test {
"configurations" : {
"launch" : {
"adapter" : " CodeLLDB " ,
"filetypes" : [ " rust " ],
"configuration" : {
"request" : " launch " ,
"program" : " ${workspaceRoot}/target/debug/vimspector_test "
}
},
"attach" : {
"adapter" : " CodeLLDB " ,
"filetypes" : [ " rust " , " c " , " cpp " , " jai " ],
"configuration" : {
"request" : " attach " ,
"program" : " ${workspaceRoot}/${fileBasenameNoExtension} " ,
"PID" : " ${PID} "
}
}
}
}"request": "custom" - これは無効です。代わりに、 "request": "launch", "custom": true使用します。理由があるからですcargoとのすべての統合は、VSCODE JavaScript Madnessで行われるため、サポートされていません。"request": customを使用します。上記の「カスタム」の起動に関するポイントを参照してくださいstep-intoの有効化） "sourceMap": { "from_path" : "to_path" }を追加して実行できます。 "from_path" 、スタックトレースに上がることにより、分解ウィンドウにあります。 "to_path"は、現在のツールチェーン用のローカルにインストールされている標準ライブラリパスです。 Jaiデバッグは、他のネイティブデバッガーのいずれかでうまく機能します。 codelldbをお勧めしますが、cpptoolsも機能します。
例：
{
"$schema" : "https://puremourning.github.io/vimspector/schema/vimspector.schema.json" ,
"adapters" : {
"gdb-with-build" : {
"extends" : "vscode-cpptools" ,
"variables" : {
"buildme" : {
"shell" : "jai ${workspaceRoot}/build.jai"
}
}
} ,
"codelldb-with-build" : {
"extends" : "CodeLLDB" ,
"variables" : {
"buildme" : {
"shell" : "jai ${workspaceRoot}/build.jai"
}
}
}
} ,
"configurations" : {
"Run - gdb" : {
"adapter" : "gdb-with-build" ,
"filetypes" : [ "jai" ] ,
"configuration" : {
"request" : "launch" ,
"program" : "${workspaceRoot}/${binaryName}" ,
"args" : [ "*${args}" ] ,
"stopAtEntry" : true ,
"stopOnEntry" : true
}
} ,
"Run - lldb" : {
"extends" : "Run - gdb" ,
"filetypes" : [ "jai" ] ,
"adapter" : "codelldb-with-build"
} ,
"Attach - gdb" : {
"adapter" : "vscode-cpptools" ,
"filetypes" : [ "jai" ] ,
"configuration" : {
"request" : "attach" ,
"program" : "${workspaceRoot}/${binaryName}" ,
"processId" : "${PID}"
}
} ,
"Attach - lldb" : {
"extends" : "Attach - gdb" ,
"filetypes" : [ "jai" ] ,
"adapter" : "CodeLLDB" ,
"configuration" : {
"pid" : "${PID}"
}
}
}
} 
Python：Debugpy
install_gadget.py --enable-pythonまたは:VimspectorInstall debugpyでインストールするには、パフォーマンスのためのC Python拡張機能を構築するために、作業コンパイラとPython開発ヘッダー/LIBSが必要です。
注：DebugpyはPython 2をサポートしなくなりました。Python2アプリケーションのデバッグを継続するには、 debugpy-python2ガジェットをインストールした後、 debugpy-python2アダプターを使用します。
完全なオプション：https：//github.com/microsoft/debugpy/wiki/debug-configuration-settings
{
"configurations" : {
"<name>: Launch" : {
"adapter" : " debugpy " ,
"filetypes" : [ " python " ],
"configuration" : {
"name" : " <name>: Launch " ,
"type" : " python " ,
"request" : " launch " ,
"cwd" : " <working directory> " ,
"python" : " /path/to/python/interpreter/to/use " ,
"stopOnEntry" : true ,
"console" : " externalTerminal " ,
"debugOptions" : [],
"program" : " <path to main python file> "
}
}
...
}
}Debugpyでリモートデバッグを使用するには、vimspectorをデバッグされているアプリケーションに直接接続する必要があります。これは簡単ですが、通常の構成方法とは少し異なります。具体的には、次のことが必要です。
--listen引数を指定します。詳細については、Debugpyドキュメントを参照してください。{
"configurations" : {
"Python Attach" : {
"adapter" : " multi-session " ,
"filetypes" : [ " python " ], // optional
"configuration" : {
"request" : " attach " ,
"pathMappings" : [
// mappings here (optional)
]
}
}
}
} pathMappingsなどの説明については、起動構成の詳細を参照してください。
リモートマシンにSSHを介してのみ連絡できる場合にこれを行う方法を含む追加のドキュメントは、Debugpyによって提供されます。
空想を感じている場合は、Vimspectorにリモートで起動して添付してもらうために、参照ガイドをチェックアウトしてください。
Python 2アプリケーションのデバッグを継続するには、 debugpy-python2ガジェット（ --force-enable-python2または:VimspectorInstall debugpy-python2 ）をインストールしてから、構成を変更するようにしてください。
{
"configurations" : {
"Python Attach" : {
"adapter" : " debugpy-python2 " ,
// ...
}
}
}
Examk用
指示については、TCLProdeBugの私のフォークを参照してください。
install_gadget.py --force-enable-csharpまたは:VimspectorInstall netcoredbg
{
"configurations" : {
"launch - netcoredbg" : {
"adapter" : " netcoredbg " ,
"filetypes" : [ " cs " , " fsharp " , " vbnet " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " ${workspaceRoot}/bin/Debug/netcoreapp2.2/csharp.dll " ,
"args" : [],
"stopAtEntry" : true ,
"cwd" : " ${workspaceRoot} " ,
"env" : {}
}
}
}
}必要：
install_gadget.py --enable-goまたは:VimspectorInstall delvego 1.16 （以前のバージョンのYMMV）これは、DELVEデバッガーに組み込まれたDAPサポートを使用します
{
"configurations" : {
"run" : {
"adapter" : " delve " ,
"filetypes" : [ " go " ], // optional
"variables" : {
// example, to disable delve's go version check
// "dlvFlags": "--check-go-version=false"
},
"configuration" : {
"request" : " launch " ,
"program" : " ${fileDirname} " ,
"mode" : " debug "
}
}
}
}変数を使用して、以下を構成します。
dlvFlags ：（文字列）渡すために渡す追加のコマンドライン引数デバッガー（DELVE）は端末ウィンドウで起動され、出力が表示され、デバッグジーへの入力を渡すことができます。
完全な起動オプションについては、vscodegoドキュメントを参照してください。はい、それは彼らが文書化されている唯一の場所のようです（明らかに、それ自体によって文書化されていません）。
VSCODEGOドキュメントには、有用なトラブルシューティング情報もあります
必要：
install_gadget.py --enable-goまたは:VimspectorInstall vscode-gogo get -u github.com/go-delve/delve/cmd/dlvdlvToolPath起動オプションを指定するか注：Vimspectorは、Delveの「組み込み」DAPサポートではなく、「レガシー」VSCODE-GOデバッグアダプターを使用しています。そのために＃186を追跡できます。
{
"configurations" : {
"run" : {
"adapter" : " vscode-go " ,
"filetypes" : [ " go " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " ${fileDirname} " ,
"mode" : " debug " ,
"dlvToolPath" : " $HOME/go/bin/dlv "
// example, to disable delve's go version check
// "dlvFlags": [ "--check-go-version=false" ]
}
}
}
}トラブルシューティング情報については、vscode-goドキュメントを参照してください
これはPHP-Debugを使用します。https：//marketplace.visualstudio.com/items？itemname=felixfbecker.php-debugを参照してください
必要：
install_gadget.py --force-enable-phpまたは:VimspectorInstall vscode-php-debug zend_extension =xdebug.so
xdebug.remote_enable =on
xdebug.remote_handler =dbgp
xdebug.remote_host =localhost
xdebug.remote_port =9000 localhostワークステーションのIPに置き換えます。
怠zyな代替品
zend_extension =xdebug.so
xdebug.remote_enable =on
xdebug.remote_handler =dbgp
xdebug.remote_connect_back =true
xdebug.remote_port =9000{
"configurations" : {
"Listen for XDebug" : {
"adapter" : " vscode-php-debug " ,
"filetypes" : [ " php " ], // optional
"configuration" : {
"name" : " Listen for XDebug " ,
"type" : " php " ,
"request" : " launch " ,
"port" : 9000 ,
"stopOnEntry" : false ,
"pathMappings" : {
"/var/www/html" : " ${workspaceRoot} "
}
}
},
"Launch currently open script" : {
"adapter" : " vscode-php-debug " ,
"filetypes" : [ " php " ], // optional
"configuration" : {
"name" : " Launch currently open script " ,
"type" : " php " ,
"request" : " launch " ,
"program" : " ${file} " ,
"cwd" : " ${fileDirname} " ,
"port" : 9000
}
}
}
}XDEBUG_SESSION_START=xdebugクエリ文字列に追加します
curl "http://localhost?XDEBUG_SESSION_START=xdebug"
または、前述のXdebugヘルパー拡張機能を使用します（ XDEBUG_SESSION Cookieを設定します）
export XDEBUG_CONFIG= " idekey=xdebug "
php < path to script > これは、VSCODEでも使用されるデバッガーであるVSCODE-JS-DEBUGを使用します。追加の構成については、こちらのドキュメントを確認してください。
vscode-js-debugをインストールするには、 VimspectorInstall vscode-js-debug Vimから実行するか、インストールスクリプトをinstall_gadget.py --force-enable-nodeを実行します。チェックアウトできる複数の例があります。 support/test/node/simple 、 support/test/node/multiprocess 、 support/test/node/typescriptの下でそれらを見つけます。 Debugging TypeScriptの典型的な構成は次のようになります。
{
"configurations" : {
"run - js-debug" : {
"adapter" : " js-debug " ,
"filetypes" : [ " javascript " , " typescript " ],
"configuration" : {
"request" : " launch " ,
"program" : " ${workspaceRoot}/src/index.ts " ,
"cwd" : " ${workspaceRoot} " ,
"stopOnEntry" : false ,
"type" : " pwa-node "
},
// 'breakpoints' is an optional part. This is a way to configure exception
// breakpoints. You can leave this out or set as you prefer.
"breakpoints" : {
"exception" : {
"all" : " N " ,
"uncaught" : " N "
}
}
}
}
}
vscode-js-debugさまざまな「タイプ」をサポートしており、機能する場合と機能しない可能性のあるものを実行できます。 typeフィールドは悲しいことに文書化されていませんが、有効な値はここでDebugType enumで定義されています。
Vimspectorはpwa-nodeタイプでのみテストされています。
また、何らかの理由で、このデバッグアダプターは常に複数のデバッグセッションを開始することを強制することに注意してください。ユーザーの場合、それは何も変更しないはずです（おそらく少し混乱するスタックトレース以外）。しかし、それは物事をより複雑にするので、微妙なバグがあるかもしれません。
これは、Chrome/Firefox Debugger（非常に似ています）を使用します。https：//marketplace.visualstudio.com/items?itemname=msjsdiag.debugger-for-chromeを参照してください。 = firefox-devtools.vscode-firefox-debug、それぞれ。
VIM内からChrome内で実行されているスクリプトをデバッグできます。
./install_gadget.py --force-enable-chromeまたは:VimspectorInstall debugger-for-chrome./install_gadget.py --force-enable-firefoxまたは:VimspectorInstall debugger-for-firefoxsupport/test/web {
"configurations" : {
"chrome" : {
"adapter" : " chrome " ,
"configuration" : {
"request" : " launch " ,
"url" : " http://localhost:1234/ " ,
"webRoot" : " ${workspaceRoot}/www "
}
},
"firefox" : {
"adapter" : " firefox " ,
"configuration" : {
"request" : " launch " ,
"url" : " http://localhost:1234/ " ,
"webRoot" : " ${workspaceRoot}/www " ,
"reAttach" : true
}
}
}
}Vimspectorは、スタンドアロンのデバッグアダプターではなく、JDT.LS（Java Language Server）プラグインとして実行されるJava Debug Serverとうまく連携しています。
Vimspectorは、言語サーバーを実行するビジネスではなく、デバッグアダプターのみであるため、Javaを使用するために互換性のあるLanguage Server Protocol Editorプラグインが必要であることを意味します。 JDT.LSを完全にサポートするYouCompleTemeをお勧めします。最も重要なのは、デバッグアダプターをロードしてVimspectorで使用する些細な方法です。
Java Debug Serverを使用する場合、VimspectorはHot Codeの交換カスタム機能をサポートします。デフォルトでは、基礎となるクラスファイルが変更されると、Vimspectorは、実行時にこれらのクラスをリロードするかどうかをユーザーに尋ねます。
この動作はカスタマイズできます。
let g:vimspector_java_hotcodereplace_mode = 'ask' - デフォルト、リロードごとにユーザーに尋ねます。let g:vimspector_java_hotcodereplace_mode = 'always'let g:vimspector_java_hotcodereplace_mode = 'never'install_gadget.py --force-enable-java <other options...>または:VimspectorInstall java-debug-adaptervscode-javaアダプターを使用してプロジェクトのVimspectorを構成します。 {
"configurations" : {
"Java Attach" : {
"adapter" : " vscode-java " ,
"filetypes" : [ " java " ],
"configuration" : {
"request" : " attach " ,
"hostName" : " ${host} " ,
"port" : " ${port} " ,
"sourcePaths" : [
" ${workspaceRoot}/src/main/java " ,
" ${workspaceRoot}/src/test/java "
]
}
}
}
}gadgets/<os>ディレクトリである必要があります。例： .vimrc " Tell YCM where to find the plugin. Add to any existing values.
let g: ycm_java_jdtls_extension_path = [
' </path/to/Vimspector/gadgets/<os> '
]<leader><F5>サーバーを起動してVimspector ~/.vim/ftplugin/java.vim起動するなどのマッピングを作成します。 let s: jdt_ls_debugger_port = 0
function ! s: StartDebugging ()
if s: jdt_ls_debugger_port <= 0
" Get the DAP port
let s: jdt_ls_debugger_port = youcompleteme#GetCommandResponse (
' ExecuteCommand ' ,
' vscode.java.startDebugSession ' )
if s: jdt_ls_debugger_port == ' '
echom " Unable to get DAP port - is JDT.LS initialized? "
let s: jdt_ls_debugger_port = 0
return
endif
endif
" Start debugging with the DAP port
call vimspector#LaunchWithSettings ( { ' DAPPort ' : s: jdt_ls_debugger_port } )
endfunction
nnoremap <silent> <buffer> <Leader><F5> :call <SID> StartDebugging() <CR>
その後、 <F5>ではなく<Leader><F5>を使用してデバッグを開始できます。
「DAPポートを取得できない-JDT.LSは初期化されていますか？」と表示されている場合は、実行してみてください:YcmCompleter ExecuteCommand vscode.java.startDebugSession実行し、出力に注意してください。 ResponseFailedException: Request failed: -32601: No delegateCommandHandler for vscode.java.startDebugSession 、次のことを確認してください。
g:ycm_java_jdtls_extension_pathは.vimrcまたはycm開始前に設定されています起動引数については、VSCODEドキュメントを参照してください。
詳細については、この問題を参照してください。
LUAは、Local-Lua-Debugger-VScodeを通じてサポートされています。このデバッガーはSTDIOを使用して実行プロセスと通信するため、 io.readへの呼び出しは問題を引き起こします。
./install_gadget.py --enable-luaまたは:VimspectorInstall local-lua-debugger-vscodesupport/test/lua/simpleで、 support/test/lua/love {
"$schema" : " https://puremourning.github.io/vimspector/schema/vimspector.schema.json# " ,
"configurations" : {
"lua" : {
"adapter" : " lua-local " ,
"filetypes" : [ " lua " ],
"configuration" : {
"request" : " launch " ,
"type" : " lua-local " ,
"cwd" : " ${workspaceFolder} " ,
"program" : {
"lua" : " lua " ,
"file" : " ${file} "
}
}
},
"luajit" : {
"adapter" : " lua-local " ,
"filetypes" : [ " lua " ],
"configuration" : {
"request" : " launch " ,
"type" : " lua-local " ,
"cwd" : " ${workspaceFolder} " ,
"program" : {
"lua" : " luajit " ,
"file" : " ${file} "
}
}
},
"love" : {
"adapter" : " lua-local " ,
"filetypes" : [ " love " ],
"configuration" : {
"request" : " launch " ,
"type" : " lua-local " ,
"cwd" : " ${workspaceFolder} " ,
"program" : {
"command" : " love "
},
"args" : [ " ${workspaceFolder} " ]
}
}
}
}UIのカスタマイズに対するサポートは非常に限られています。
Vimsectorは、次の兆候を内部的に使用します。 Vimsectorがそれらを使用する前に定義されている場合、それらは交換されません。したがって、サインをカスタマイズするには、 vimrcでそれらを定義します。
| サイン | 説明 | 優先度 |
|---|---|---|
vimspectorBP | ラインブレークポイント | 9 |
vimspectorBPCond | 条件付きラインブレークポイント | 9 |
vimspectorBPLog | ログポイント | 9 |
vimspectorBPDisabled | 無効なブレークポイント | 9 |
vimspectorPC | プログラムカウンター（つまり現在の行） | 200 |
vimspectorPCBP | プログラムカウンターとブレークポイント | 200 |
vimspectorNonActivePC | 非焦点スレッドのプログラムカウンター | 9 |
vimspectorCurrentThread | スタックトレースビューの焦点を合わせたスレッド | 200 |
vimspectorCurrentFrame | スタックトレースビューの現在のスタックフレーム | 200 |
デフォルトのシンボルは、次のようなものに相当します。
sign define vimspectorBP text = ● texthl = WarningMsg
sign define vimspectorBPCond text = ◆ texthl = WarningMsg
sign define vimspectorBPLog text = ◆ texthl = SpellRare
sign define vimspectorBPDisabled text = ● texthl = LineNr
sign define vimspectorPC text = ▶ texthl = MatchParen linehl = CursorLine
sign define vimspectorPCBP text = ●▶ texthl = MatchParen linehl = CursorLine
sign define vimspectorNonActivePC linehl = DiffAdd
sign define vimspectorCurrentThread text = ▶ texthl = MatchParen linehl = CursorLine
sign define vimspectorCurrentFrame text = ▶ texthl = Special linehl = CursorLine標識が適切に表示されない場合、フォントはおそらくこれらのグリフが含まれていません。 VIMRCのサインを定義することで、簡単に変更できます。たとえば、これをvimrcに入れて、いくつかの単純なASCIIシンボルを使用できます。
sign define vimspectorBP text = o texthl = WarningMsg
sign define vimspectorBPCond text = o ? texthl = WarningMsg
sign define vimspectorBPLog text = !! texthl = SpellRare
sign define vimspectorBPDisabled text = o ! texthl = LineNr
sign define vimspectorPC text = > texthl = MatchParen
sign define vimspectorPCBP text = o > texthl = MatchParen
sign define vimspectorCurrentThread text = > texthl = MatchParen
sign define vimspectorCurrentFrame text = > texthl = Special 多くの異なるプラグインは、さまざまな目的の標識を提供します。例には、コードエラーなどの診断標識が含まれます。VIMは、複数の符号が単一の行に配置されたときに表示する符号を決定するための単一の優先度のみを提供します。他の兆候がVimspectorの（またはその逆）に干渉していることがわかっている場合は、次の辞書を設定してVimspectorが使用する優先度をカスタマイズできます。
let g: vimspector_sign_priority = {
' <sign-name> ' : <priority> ,
}例えば：
let g: vimspector_sign_priority = {
' vimspectorBP ' : 3 ,
' vimspectorBPCond ' : 3 ,
' vimspectorBPLog ' : 3 ,
' vimspectorBPDisabled ' : 3 ,
' vimspectorNonActivePC ' : 3 ,
' vimspectorPC ' : 999 ,
' vimspectorPCBP ' : 999 ,
}すべてのキーはオプションです。サインがカスタマイズされていない場合、使用したデフォルトの優先度（上記のように）。
参照:help sign-priority 。デフォルトの優先順位は10で、より多くの数が小さいものを上書きします。
注：デフォルトのvimspectorNonActivePCサインは、サイン列にテキストを追加しません。他のスレッドまたはプロセスが現在停止されている行を見ることができるように、ラインハイライトを追加するだけです。その結果、この記号は通常、シンボル（ブレークポイントサインなど）を追加する任意の記号とマージする必要があります。 VIMは、サインのプロパティを同じ優先順位でマージするため、デフォルトの優先順位を変更する場合は、次のことをお勧めします。
vimspectorBP 、 vimspectorBPCondなど）にも同じ優先順位があります。vimspectorNonActivePC符号を同じ優先順位に設定しますvimspectorPC 、 vimspectorPCBPなど）の優先度が高くなっています。 注：このカスタマイズポイントは現在不可能であり、いつでも変更される可能性があります。
デバッグアダプターは、UIが特定のものを表示する方法に関するヒントを提供する場合があります。これには、スタックフレーム、変数などが含まれます。
vimspectorは、辞書g:vimsepctor_presentation_hint_hlに値を設定することにより、これらの表示方法をカスタマイズする簡単な方法を提供します。
次のキーは、上記のデフォルトハイライトグループでサポートされています。
| グループ | 鍵 | 使用法 | デフォルト |
|---|---|---|---|
| 全て | normal | 以下でカバーされていないもの | Normal |
| スタックトレース | emphasize | スタックトレースのソースを強調します | Title |
| スタックトレース | deemphasize | スタックトレースのソースを重化します | Conceal |
| スタックトレース | label | 実際のフレームを表すのではなく、「ラベル」であるスタックフレーム | NonText |
| スタックトレース | subtle | 内部または面白くないスタックフレーム | Conceal |
| スコープ | arguments | 関数引数の範囲 | Title |
| スコープ | locals | ローカル変数の範囲 | Title |
| スコープ | registers | レジスタスコープ | Title |
| 変数 | property | 関数引数の範囲 | Identifier |
| 変数 | method | ローカル変数の範囲 | Function |
| 変数 | class | レジスタスコープ | Type |
| 変数 | data | レジスタスコープ | String |
さらに、DAP VariablePresentationHintで提供される値を設定できます。これは、デバッグアダプターから提供された場合に使用されます。
愚かな例;デフォルトは、おそらくほとんどの色のscehemでは問題ないはずです：
let g: vimspector_presentation_hint_hl = {
' normal ' : ' Identifier ' ,
' label ' : ' Title ' ,
}注：このカスタマイズAPIは不安定であるため、いつでも変更される可能性があります。私はこれの影響を減らし、Gitterの変化を発表するよう努めます。
次のオプションは、UIウィンドウのデフォルトサイズを制御します（それらはすべて数字です）
g:vimspector_sidebar_width （デフォルト：50列）：左のユーティリティウィンドウの列の幅（変数、時計、スタックトレース）g:vimspector_bottombar_height （デフォルト10行）：コードウィンドウの下の出力ウィンドウの列の高さ。例：
let g: vimspector_sidebar_width = 75
let g: vimspector_bottombar_height = 15 The terminal is typically created as a vertical split to the right of the code window, and that window is re-used for subsequent terminal buffers. The following control the sizing of the terminal window used for debuggee input/output when using Vim's built-in terminal.
g:vimspector_code_minwidth (default: 82 columns): Minimum number of columns to try and maintain for the code window when splitting to create the terminal window.g:vimspector_terminal_maxwidth (default: 80 columns): Maximum number of columns to use for the terminal.g:vimspector_terminal_minwidth (default: 10 columns): Minimum number of columns to use when it is not possible to fit g:vimspector_terminal_maxwidth columns for the terminal. That's a lot of options, but essentially we try to make sure that there are at least g:vimspector_code_minwidth columns for the main code window and that the terminal is no wider than g:vimspector_terminal_maxwidth columns. g:vimspector_terminal_minwidth is there to ensure that there's a reasonable number of columns for the terminal even when there isn't enough horizontal space to satisfy the other constraints.
例：
let g: vimspector_code_minwidth = 90
let g: vimspector_terminal_maxwidth = 75
let g: vimspector_terminal_minwidth = 20 It's useful to be able to define mappings only while debugging and remove those mappings when debugging is complete. For this purpose, Vimspector provides 2 User autocommands:
VimspectorJumpedToFrame - triggered whenever a 'break' event happens, or when selecting a stack from to jump to. This can be used to create (for example) buffer-local mappings for any files opened in the code window.VimspectorDebugEnded - triggered when the debug session is terminated (actually when Vimspector is fully reset) An example way to use this is included in support/custom_ui_vimrc . In there, these autocommands are used to create buffer-local mappings for any files visited while debugging and to clear them when completing debugging. This is particularly useful for commands like <Plug>VimspectorBalloonEval which only make sense while debugging (and only in the code window). Check the commented section Custom mappings while debugging .
NOTE: This is a fairly advanced feature requiring some nontrivial vimscript. It's possible that this feature will be incorporated into Vimspector in future as it is a common requirement.
In many cases you will want to rebuild your project before starting a new debugging session. Vimspector is not a task manager and implementing this functionality is out of the scope of this project. However, there are some strategies described in the community wiki to achieve similar functionality.
You can tell vimspector not to draw the WinBar (the toolbars in the code, variables, output, etc. windows) by setting:
let g: vimspector_enable_winbar = 0The WinBar is in any case not displayed if the mouse is not enabled.
Please Note : This customisation API is unstable , meaning that it may change at any time. I will endeavour to reduce the impact of this and announce changes in Gitter.
The above customisation of window sizes is limited intentionally to keep things simple. Vimspector also provides a way for you to customise the UI without restrictions, by running a User autocommand just after creating the UI or opening the terminal. This requires you to write some vimscript, but allows you to do things like:
You can essentially do anything you could do manually by writing a little vimscript code.
The User autocommand is raised with pattern set with the following values:
VimspectorUICreated : Just after setting up the UI for a debug sessionVimspectorTerminalOpened : Just after opening the terminal window for program input/output. The following global variable is set up for you to get access to the UI elements: g:vimspector_session_windows . This is a dict with the following keys:
g:vimspector_session_windows.tabpage : The tab page for the sessiong:vimspector_session_windows.variables : Window ID of the variables window, containing the vimspector.Variables buffer.g:vimspector_session_windows.watches : Window ID of the watches window, containing the vimspector.Watches buffer.g:vimspector_session_windows.stack_trace : Window ID of the stack trade window containing the vimspector.StackTrace buffer.g:vimspector_session_windows.code : Window ID of the code window.g:vimspector_session_windows.output : Window ID of the output window. In addition, the following key is added when triggering the VimspectorTerminalOpened event:
g:vimspector_session_windows.terminal : Window ID of the terminal window You can even customise the WinBar buttons by simply running the usual menu (and unmenu ) commands.
By default, Vimspector uses something a bit like this:
nnoremenu WinBar.■ Stop : call vimspector#Stop ( { ' interactive ' : v: false } ) <CR>
nnoremenu WinBar.▶ Cont : call vimspector#Continue () <CR>
nnoremenu WinBar.▷ Pause : call vimspector#Pause () <CR>
nnoremenu WinBar.↷ Next : call vimspector#StepOver () <CR>
nnoremenu WinBar.→ Step : call vimspector#StepInto () <CR>
nnoremenu WinBar.← Out : call vimspector#StepOut () <CR>
nnoremenu WinBar.⟲: : call vimspector#Restart () <CR>
nnoremenu WinBar.✕ : call vimspector#Reset ( { ' interactive ' : v: false } ) <CR> If you prefer a different layout or if the unicode symbols don't render correctly in your font, you can customise this in the VimspectorUICreated autocommand, for example:
func ! CustomiseUI ()
call win_gotoid ( g: vimspector_session_windows .code )
" Clear the existing WinBar created by Vimspector
nunmenu WinBar
" Create our own WinBar
nnoremenu WinBar.Kill : call vimspector#Stop ( { ' interactive ' : v: true } ) <CR>
nnoremenu WinBar. Continue : call vimspector#Continue () <CR>
nnoremenu WinBar.Pause : call vimspector#Pause () <CR>
nnoremenu WinBar. Step Over : call vimspector#StepOver () <CR>
nnoremenu WinBar. Step In : call vimspector#StepInto () <CR>
nnoremenu WinBar. Step Out : call vimspector#StepOut () <CR>
nnoremenu WinBar.Restart : call vimspector#Restart () <CR>
nnoremenu WinBar.Exit : call vimspector#Reset () <CR>
endfunction
augroup MyVimspectorUICustomistaion
autocmd !
autocmd User VimspectorUICreated call s: CustomiseUI ()
augroup END There is some example code in support/custom_ui_vimrc showing how you can use the window IDs to modify various aspects of the UI using some basic vim commands, primarily win_gotoid function and the wincmd ex command.
To try this out vim -Nu support/custom_ui_vimrc <some file> .
Here's a rather smaller example. A simple way to use this is to drop it into a file named my_vimspector_ui.vim in ~/.vim/plugin (or paste into your vimrc ):
" Set the basic sizes
let g: vimspector_sidebar_width = 80
let g: vimspector_code_minwidth = 85
let g: vimspector_terminal_minwidth = 75
function ! s: CustomiseUI ()
" Customise the basic UI...
" Close the output window
call win_gotoid ( g: vimspector_session_windows .output )
q
endfunction
function s: SetUpTerminal ()
" Customise the terminal window size/position
" For some reasons terminal buffers in Neovim have line numbers
call win_gotoid ( g: vimspector_session_windows . terminal )
set norelativenumber nonumber
endfunction
augroup MyVimspectorUICustomistaion
autocmd !
autocmd User VimspectorUICreated call s: CustomiseUI ()
autocmd User VimspectorTerminalOpened call s: SetUpTerminal ()
augroup END.vimspector.json . As you can see above, some of the servers aren't really editor agnostic, and require very-specific unique handling. See the wiki for details on additional language support.vimspector.json ? Yes, see here..vimspector.json , or could it be the current vim file?その必要はありません。 You can specify $file for the current active file. See here for complete list of replacements in the configuration file..vimspector.json , but Vim highlights these as errors, do you know how to make this not-an-error? Yes, put this in ~/.vim/after/syntax/json.vim : syn region jsonComment start = " / * " end = " * / "
hi link jsonCommentError Comment
hi link jsonComment Commentgadget and an adapter ? A gadget is something you install with :VimspectorInstall or install_gadget.py , an adapter is something that Vimspector talks to (actually it's the Vimspector config describing that thing). These are usually one-to-one, but in theory a single gadget can supply multiple adapter configs. Typically this happens when a gadget supplies different adapter config for, say remote debugging, or debugging in a container, etc..vimspector.json in the root of every project? No, you can use g:vimspector_adapters and g:vimspector_configurations or put all of your adapter and debug configs in a single directory if you want to, but note the caveat that ${workspaceRoot} won't be calculated correctly in that case. The vimsepctor author uses this a lotvimspector#LaunchWithSettings( { 'ThePID': the_pid_i_picked } ) . Alternatively, you could use a shell variable to guess the PID, like this (which runs pgrep vim | sort | tail -1 to get the 'highest' PID of the command to be debugged (NOTE: this is for debugging Vim. replace with something appropriate to your actual use case. If this doesn't make sense to you, you might be better off just typing in the PID). "Attach: max PID" : {
"adapter" : " CodeLLDB " ,
"variables" : {
"pid" : {
"shell" : [
" /bin/bash " ,
" -c " ,
" pgrep vim | sort | tail -1 "
]
}
},
"configuration" : {
"request" : " attach " ,
"program" : " ${workspaceRoot}/src/vim " ,
"expressions" : " native " ,
"stopOnEntry#json" : " ${StopOnEntry:true} " ,
"pid" : " ${pid} "
}
}, Example g:vimspector_adapters and g:vimspector_configurations :
let g: vimspector_adapters = #{
test_debugpy: #{ extend s: ' debugpy ' }
}
let g: vimspector_configurations = {
" test_debugpy_config " : {
" adapter " : " test_debugpy " ,
" filetypes " : [ " python " ],
" configuration " : {
" request " : " launch " ,
" type " : " python " ,
" cwd " : " ${fileDirname} " ,
" args " : [],
" program " : " ${file} " ,
" stopOnEntry " : v: false ,
" console " : " integratedTerminal " ,
" integer " : 123 ,
},
" breakpoints " : {
" exception " : {
" raised " : " N " ,
" uncaught " : " " ,
" userUnhandled " : " "
}
}
} }
