vimspector
1.0.0
Eine Anleitung und einen Überblick über die Verwendung finden Sie auf der Vimspector-Website.
Eine ausführliche Erläuterung des .vimspector.json -Formats finden Sie im Referenzhandbuch.
Das Plugin ist ein leistungsfähiger grafischer Vim-Debugger für mehrere Sprachen. Es wurde hauptsächlich für C++, Python und TCL getestet, unterstützt aber theoretisch jede Sprache, die Visual Studio Code unterstützt (siehe jedoch Einschränkungen).
Auf der Vimspector-Website finden Sie einen Überblick über die Benutzeroberfläche sowie grundlegende Anweisungen zur Konfiguration und Einrichtung.
Aber für den Moment ist hier ein (ziemlich alter) Screenshot von Vimspector beim Debuggen von Vim:
Und ein paar kurze Demos:
<Plug>VimspectorBalloonEval )In der folgenden Tabelle sind die „integrierten“ Sprachen aufgeführt (zusammen mit ihren Laufzeitabhängigkeiten). Sie werden nach ihrem Unterstützungsgrad kategorisiert:
Tested : Vollständig unterstützt, Vimspector-Regressionstests decken diese abSupported : Vollständig unterstützt, häufig verwendet und manuell getestetExperimental : Funktioniert, aber nicht häufig verwendet und selten getestetLegacy : Wird nicht mehr unterstützt. Bitte migrieren Sie Ihre KonfigurationRetired : Nicht mehr enthalten oder unterstützt.| Sprache(n) | Status | Schalter (für install_gadget.py ) | Adapter (für :VimspectorInstall ) | Abhängigkeiten |
|---|---|---|---|---|
| C, C++, Rust, Jai usw. | Getestet | --all oder --enable-c (oder cpp) | vscode-cpptools | Monokern |
| C, C++, Rust, Jai usw. | Getestet | --enable-rust , --enable-c usw. | CodeLLDB | keiner |
| Python | Getestet | --all oder --enable-python | debugpy | Python 3 |
| Gehen | Getestet | --enable-go | vertiefen | Gehen Sie 1.16+ |
| TCL | Unterstützt | --all oder --enable-tcl | tclpro | TCL 8.5 |
| Bourne Shell | Unterstützt | --all oder --enable-bash | vscode-bash-debug | Bash v?? |
| Lua | Getestet | --all oder --enable-lua | local-lua-debugger-vscode | Knoten >=12.13.0, Npm, Lua-Interpreter |
| Node.js | Unterstützt | --force-enable-node | vscode-js-debug | Knoten >= 18 |
| Javascript | Unterstützt | --force-enable-chrome | Debugger für Chrome | Chrom |
| Javascript | Unterstützt | --force-enable-firefox | vscode-firefox-debug | Firefox |
| Java | Unterstützt | --force-enable-java | vscode-java-debug | Kompatibles LSP-Plugin (siehe später) |
| PHP | Experimental | --force-enable-php | vscode-php-debug | Knoten, PHP, XDEBUG |
| C# (Dotnet Core) | Getestet | --force-enable-csharp | netcoredbg | DotNet-Kern |
| F#, VB usw. | Unterstützt | --force-enable-[fsharp,vbnet] | netcoredbg | DotNet-Kern |
| Go (Legacy) | Vermächtnis | --enable-go | vscode-go | Knoten, los, tauchen |
| Python 2 | Vermächtnis | --force-enable-python2 | debugpy-python2 | Python 2.7 |
Vimspector sollte für jeden Debug-Adapter funktionieren, der in Visual Studio Code funktioniert.
Informationen zur Verwendung von Vimspector mit einer Sprache, die nicht „integriert“ ist, finden Sie auf dieser Wiki-Seite.
Es gibt 2 Installationsmethoden:
:help packages .packadd! vimspector zu Ihrem .vimrc.vimspector.json oder legen Sie g:vimspector_configurations fest) – siehe ReferenzhandbuchÜberprüfen Sie die Abhängigkeiten
Sehen Sie sich die Dokumentation des Plugin-Managers an und installieren Sie das Plugin. Für Vundle verwenden Sie:
Plugin ' puremourning/vimspector 'Installieren Sie einige „Gadgets“ (Debug-Adapter) – hier finden Sie Installationsbefehle und wählen Sie die zu installierenden Gadgets aus
Konfigurieren Sie die Debug-Profile Ihres Projekts (erstellen Sie .vimspector.json oder legen Sie g:vimspector_configurations fest) – siehe Referenzhandbuch
Die folgenden Abschnitte erweitern den obigen kurzen Überblick.
Vimspector erfordert:
Welche Linux-Versionen? Ich teste nur auf Ubuntu 20.04 und höher und RHEL 7.
neovim implementiert keine Maus-Hover-Ballons. Stattdessen gibt es die <Plug>VimspectorBalloonEval -Zuordnung. Dafür gibt es keine Standardzuordnung, daher empfehle ich so etwas, um die Variablenanzeige in einem Popup zu erhalten:
" 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> VimspectorBalloonEvalDie folgenden Funktionen sind für Windows nicht implementiert:
Wenn Sie vimspector einfach ausprobieren möchten, ohne Ihre vim-Konfiguration zu ändern, finden Sie in support/test Beispielprojekte für eine Reihe von Sprachen, darunter:
Um eines davon zu testen, wechseln Sie in das Verzeichnis und führen Sie Folgendes aus:
vim -Nu /path/to/vimspector/tests/vimrc --cmd "let g:vimspector_enable_mappings='HUMAN'"
Drücken Sie dann <F5> .
Es gibt auch ein C++-Projekt in tests/testdata/cpp/simple/ mit einem Makefile , mit dem überprüft werden kann, ob alles funktioniert. Dies wird von den Regressionstests in CI verwendet, sollte also immer funktionieren und ist eine gute Möglichkeit, zu überprüfen, ob das Problem eher an Ihrer Konfiguration als an einem Fehler liegt.
Es gibt viele Vim-Plugin-Manager, und ich werde keine bestimmte Präferenz angeben. Wenn Sie sich also für die Verwendung eines Plugins entscheiden, befolgen Sie die Dokumentation des Plugin-Managers. Für Vundle verwenden Sie beispielsweise:
Plugin ' puremourning/vimspector 'Wenn Sie noch keinen Plugin-Manager verwenden, installieren Sie vimspector als Vim-Paket, indem Sie dieses Repository wie folgt in Ihren Paketpfad klonen:
$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector
.vimrc , um beispielsweise die Standardzuordnungen zu aktivieren: let g: vimspector_enable_mappings = ' HUMAN '.vimrc hinzugefügt werden, nachdem Sie vimspector konfiguriert haben: packadd! vimspector
Ein Minimalbeispiel finden Sie support/doc/example_vimrc.vim .
Vimspector ist ein generischer Client für Debug-Adapter. Debug-Adapter (als „Gadgets“ oder „Adapter“ bezeichnet) sind es, die tatsächlich die Arbeit erledigen, mit den echten Debuggern zu kommunizieren.
Damit Vimspector nützlich ist, müssen einige Adapter installiert sein.
Dafür gibt es mehrere Möglichkeiten:
:VimspectorInstall <adapter> <args...> (verwenden Sie das TAB- wildmenu , um die Optionen anzuzeigen, akzeptiert auch alle install_gadget.py -Optionen)python3 install_gadget.py <args> (verwenden Sie --help , um alle Optionen anzuzeigen):VimspectorUpdate , um die neuesten unterstützten Versionen der Gadgets zu installieren.Hier ist eine Demo einiger Installationen und eines Upgrades:
Sowohl install_gadget.py als auch :VimspectorInstall führen die gleichen Aufgaben aus, obwohl sich die Standardverhaltensweisen geringfügig unterscheiden. Für unterstützte Sprachen werden sie:
gadgetDir -Symlinks für die Plattform ein.Um beispielsweise den getesteten Debug-Adapter für eine Sprache zu installieren, führen Sie Folgendes aus:
| Zu installieren | Skript | Befehl |
|---|---|---|
<adapter> | :VimspectorInstall <adapter> | |
<adapter1> , <adapter2> , ... | :VimspectorInstall <adapter1> <adapter2> ... | |
<language> | ./install_gadget.py --enable-<language> ... | :VimspectorInstall --enable-<language> ... |
| Unterstützte Adapter | ./install_gadget.py --all | :VimspectorInstall --all |
| Unterstützte Adapter, jedoch nicht TCL | ./install_gadget.py --all --disable-tcl | :VimspectorInstall --all --disable-tcl |
| Unterstützte und experimentelle Adapter | ./install_gadget.py --all --force-all | :VimspectorInstall --all |
| Adapter für spezifische Debug-Konfiguration | Von Vimspector beim Starten des Debuggens vorgeschlagen |
:VimspectorInstall führt install_gadget.py im Hintergrund aus, wobei einige der Optionen standardmäßig verwendet werden.
:VimspectorUpdate führt install_gadget.py aus, um alle bereits in Ihrer .gadgets.json installierten Gadgets neu zu installieren (d. h. zu aktualisieren).
Die Ausgabe ist minimal. Um die vollständige Ausgabe zu sehen, fügen Sie --verbose zum Befehl hinzu, wie in :VimspectorInstall --verbose ... oder :VimspectorUpdate --verbose ... .
Wenn die Installation erfolgreich ist, wird das Ausgabefenster geschlossen (und die Ausgabe geht für immer verloren). Verwenden Sie ein ! um es offen zu halten (z. B. :VimspectorInstall! --verbose --all oder :VimspectorUpdate! (usw.).
Wenn Sie im Voraus wissen, welche Gadgets Sie installieren möchten, um beispielsweise Ihre Konfiguration aus der Quellcodeverwaltung reproduzieren zu können, können Sie g:vimspector_install_gadgets auf eine Liste von Gadgets festlegen. Dies wird verwendet, wenn:
:VimspectorInstall ohne Argumente, oder:VimspectorUpdateZum Beispiel:
let g: vimspector_install_gadgets = [ ' debugpy ' , ' vscode-cpptools ' , ' CodeLLDB ' ] Standardmäßig überschreibt install_gadget.py Ihre .gadgets.json mit den gerade installierten Adaptern, während :VimspectorInstall sie aktualisiert und nur neu geänderte oder installierte Adapter überschreibt.
Wenn Sie mit dem Skript einfach einen neuen Adapter hinzufügen möchten, ohne die vorhandenen zu zerstören, fügen Sie --update-gadget-config hinzu, wie in:
$ ./install_gadget.py --enable-tcl
$ ./install_gadget.py --enable-rust --update-gadget-config
$ ./install_gadget.py --enable-java --update-gadget-config Wenn Sie configurations außerhalb des Vimspector-Repositorys beibehalten möchten (dies kann nützlich sein, wenn Sie über benutzerdefinierte Gadgets oder globale Konfigurationen verfügen), können Sie dem Installationsprogramm mitteilen, dass es ein anderes Basisverzeichnis verwenden soll, und dann beispielsweise g:vimspector_base_dir so festlegen, dass es auf dieses Verzeichnis verweist :
$ ./install_gadget.py --basedir $HOME /.vim/vimspector-config --all --force-all Fügen Sie dann Folgendes zu Ihrer .vimrc hinzu:
let g: vimspector_base_dir = expand ( ' $HOME/.vim/vimspector-config ' ) Bei Verwendung von :VimspectorInstall wird die Einstellung g:vimspector_base_dir berücksichtigt, es sei denn, --basedir wird manuell hinzugefügt (nicht empfohlen).
Weitere Informationen zu den verschiedenen Optionen finden Sie unter --help .
Wenn die Sprache, die Sie debuggen möchten, nicht in der oben aufgeführten Liste der unterstützten Sprachen enthalten ist, können Sie sie wahrscheinlich trotzdem zum Laufen bringen, aber das ist mit mehr Aufwand verbunden.
Sie müssen im Wesentlichen eine funktionierende Installation des Debug-Adapters erhalten, herausfinden, wie Sie ihn starten, und dies in einem adapters entweder in Ihrer .vimspector.json oder in .gadgets.json oder in g:vimspector_adapters konfigurieren.
In der Praxis ist es am einfachsten, Visual Studio Code zu installieren oder zu starten und über dessen Erweiterungsmanager die entsprechende Erweiterung zu installieren. Sie können den Adapter dann manuell im Abschnitt adapters Ihrer .vimspector.json oder in einer gadgets.json oder in g:vimspector_adapters konfigurieren.
PRs sind jederzeit willkommen, unterstützte Sprachen hinzuzufügen (was grob übersetzt bedeutet, python/vimspector/gadgets.py zu aktualisieren und zu testen).
Vimspector verwendet standardmäßig das folgende Verzeichnis, um nach einer Datei mit dem Namen .gadgets.json zu suchen: </path/to/vimspector>/gadgets/<os> .
Dieser Pfad wird als Vimspector- Variable ${gadgetDir} angezeigt. Dies ist nützlich für die Konfiguration von Gadget-Befehlszeilen.
Wobei os eines von:
macoslinuxwindows (Hinweis: Windows wird nicht unterstützt) Das Format ist das gleiche wie .vimspector.json , es wird jedoch nur der adapters verwendet:
Beispiel:
{
"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 "
}
}
} Die Gadget-Datei wird automatisch von install_gadget.py (oder :VimspectorInstall ) geschrieben.
Vimspector lädt auch alle Dateien, die mit Folgendem übereinstimmen: </path/to/vimspector>/gadgets/<os>/.gadgets.d/*.json . Diese haben das gleiche Format wie .gadgets.json , werden jedoch beim Ausführen install_gadget.py nicht überschrieben.
Nachdem Sie den Vimspector-Code aktualisiert haben (entweder über git pull oder einen anderen Paketmanager), führen Sie :VimspectorUpdate aus, um alle bereits installierten Gadgets zu aktualisieren.
Der Grund dafür ist, dass das Debuggen in Vim eine ziemlich schreckliche Erfahrung ist, insbesondere wenn Sie mehrere Sprachen verwenden. Da es kein Pyclewn mehr gibt und das integrierte Termdebug-Plugin auf GDB beschränkt ist, wollte ich Optionen erkunden.
Während das Language Server Protocol bekannt ist, ist das Debug Adapter Protocol weniger bekannt, erreicht aber ein ähnliches Ziel: eine sprachunabhängige API, die Debugger von Clients abstrahiert.
Das Ziel dieses Projekts besteht darin, ein einfaches, aber effektives Debugging-Erlebnis in Vim für mehrere Sprachen bereitzustellen, indem die Debug-Adapter genutzt werden, die für Visual Studio Code erstellt werden.
Die Fähigkeit zum Remote-Debugging ist ein Muss. Dies ist der Schlüssel zu meinem Arbeitsablauf, daher ist die Einbindung in die Debugging-Erfahrung ein oberstes Rechnungsziel für das Projekt. Vimspector bietet also erstklassige Unterstützung für die Remote-Ausführung von Programmen und deren Anbindung. Diese Unterstützung gibt es nur bei vimspector und zusätzlich (ergänzend) zu jeder solchen Unterstützung in tatsächlichen Debug-Adaptern.
Vimspector ist eine VIM-Benutzeroberfläche auf Basis des Debug Adapter Protocol. Es soll auf hohem Niveau und praktisch für alltägliche Debugging-Aufgaben sein.
Vimspector ist nicht:
Vimspector ist in Arbeit und jegliches Feedback/Beitrag ist mehr als willkommen.
Der Backlog kann auf Trello eingesehen werden.
Das Plugin ist derzeit experimentell . Das bedeutet, dass sich jeder Teil davon ändern kann (und wahrscheinlich auch tun wird), einschließlich Dinge wie:
Ich verpflichte mich jedoch, dies nur in den extremsten Fällen zu tun und solche Änderungen rechtzeitig auf Gitter anzukündigen. Es gibt nichts Ärgerlicheres, als wenn einem einfach etwas kaputt geht. Das verstehe ich.
Eine Nachricht des Autors zur Motivation für dieses Plugin:
Viele Entwicklungsumgebungen verfügen über einen integrierten Debugger. Ich verbringe übermäßig viel Zeit in Vim. Ich mache meine gesamte Entwicklung in Vim und habe sogar meine Arbeitsabläufe zum Erstellen von Code, zum Ausführen von Tests usw. angepasst.
Seit vielen Jahren beobachte ich, wie ich selbst, meine Freunde und Kollegen
printf,puts,Ich bin fest davon überzeugt, dass interaktive, grafische Debugging-Umgebungen die beste Möglichkeit sind, sowohl unbekannten als auch vertrauten Code zu verstehen und darüber nachzudenken, und dass der Mangel an einem einfachen, einfachen Zugriff auf einen Debugger für viele ein großes, verstecktes Produktivitätsloch darstellt.
Verstehen Sie mich nicht falsch, ich weiß, dass es buchstäblich Millionen von Entwicklern gibt, die mehr als kompetent darin sind, ohne grafischen Debugger zu entwickeln, aber ich behaupte, wenn sie die Möglichkeit hätten, einfach eine Taste zu drücken und in den Debugger zu springen, wäre es das wäre schneller und angenehmer als nur das Verstehen von Codes im Gehirn.
Ich habe Vimspector erstellt, weil ich den Wechsel von Tools frustrierend finde.
gdbfür C++,pdbfür Python usw. Jedes hat seine eigene Syntax. Jeder hat sein eigenes Lexikon. Jeder hat seine eigenen Schwächen.Ich habe das Konfigurationssystem so entworfen, dass die Konfiguration der Quellcodeverwaltung übergeben werden kann, sodass sie für jeden Ihrer Kollegen, Freunde, Mitarbeiter oder völlig Fremden funktioniert .
Ich habe das Remote-Debugging zu einer erstklassigen Funktion gemacht, da dies für mich in meinem Job ein Hauptanwendungsfall ist.
Mit Vimspector kann ich in allen Sprachen, in denen ich entwickle, einfach
<F5>drücken und lokal oder remote mit genau demselben Workflow, denselben Zuordnungen und derselben Benutzeroberfläche debuggen. Ich habe dies so in meinen Vim integriert, dass ich auf Knopfdruck den Test unter dem Cursor in Vimspector ausführen kann. Diese Art der Integration hat meinen Arbeitsablauf und meine Produktivität enorm verbessert. Es hat sogar den Prozess des Erlernens einer neuen Codebasis ... zum Spaß gemacht.– Ben Jackson, Schöpfer.
Apache 2.0
Copyright © 2018 Ben Jackson
Wenn Ihnen Vimspector so gut gefällt, dass Sie bereit sind, Ihr hart verdientes Geld abzugeben, denken Sie bitte über eine Spende an eine der folgenden Wohltätigkeitsorganisationen nach, die für den Autor von Vimspector von Bedeutung sind (in der Reihenfolge ihrer Präferenz):
Standardmäßig ändert vimspector keine Ihrer Zuordnungen. Zuordnungen sind sehr persönlich und Sie sollten daher herausfinden, was Ihnen gefällt, und die leistungsstarken Zuordnungsfunktionen von vim verwenden, um Ihre eigenen Zuordnungen festzulegen. Zu diesem Zweck definiert Vimspector die folgenden <Plug> -Zuordnungen:
| Abbildung | Funktion | API |
|---|---|---|
<Plug>VimspectorContinue | Fahren Sie beim Debuggen fort. Andernfalls beginnen Sie mit dem Debuggen. | vimspector#Continue() |
<Plug>VimspectorStop | Hören Sie mit dem Debuggen auf. | vimspector#Stop() |
<Plug>VimpectorRestart | Starten Sie das Debuggen mit derselben Konfiguration neu. | vimspector#Restart() |
<Plug>VimspectorPause | Debugger anhalten. | vimspector#Pause() |
<Plug>VimspectorBreakpoints | Haltepunktfenster ein-/ausblenden | vimspector#ListBreakpoints() |
<Plug>VimspectorToggleBreakpoint | Zeilenhaltepunkt in der aktuellen Zeile umschalten. | vimspector#ToggleBreakpoint() |
<Plug>VimspectorToggleConditionalBreakpoint | Schalten Sie den bedingten Zeilenhaltepunkt oder Protokollpunkt in der aktuellen Zeile um. | vimspector#ToggleBreakpoint( { trigger expr, hit count expr } ) |
<Plug>VimspectorAddFunctionBreakpoint | Fügen Sie einen Funktionshaltepunkt für den Ausdruck unter dem Cursor hinzu | vimspector#AddFunctionBreakpoint( '<cexpr>' ) |
<Plug>VimspectorGoToCurrentLine | Setzt den aktuellen Programmzähler auf die aktuelle Zeile zurück | vimspector#GoToCurrentLine() |
<Plug>VimspectorRunToCursor | Zum Cursor laufen | vimspector#RunToCursor() |
<Plug>VimspectorStepOver | Steigen Sie hinüber | vimspector#StepOver() |
<Plug>VimspectorStepInto | Treten Sie ein | vimspector#StepInto() |
<Plug>VimspectorStepOut | Verlassen Sie den aktuellen Funktionsumfang | vimspector#StepOut() |
<Plug>VimspectorDisassemble | Demontage anzeigen. Aktivieren Sie die Anweisungsweiterschaltung | vimspector#ShowDisassembly() |
<Plug>VimspectorUpFrame | Im aktuellen Aufrufstapel einen Frame nach oben verschieben | vimspector#UpFrame() |
<Plug>VimspectorDownFrame | Im aktuellen Aufrufstapel einen Frame nach unten bewegen | vimspector#DownFrame() |
<Plug>VimspectorJumpToNextBreakpoint | Bewegen Sie den Cursor zum nächsten Haltepunkt in der aktuellen Datei | vimspector#JumpToNextBreakpoint() |
<Plug>VimspectorJumpToPreviousBreakpoint | Bewegen Sie den Cursor zum vorherigen Haltepunkt in der aktuellen Datei | vimspector#JumpToPreviousBreakpoint() |
<Plug>VimspectorJumpToProgramCounter | Bewegen Sie den Cursor zum Programmzähler im aktuellen Frame | vimspector#JumpToProgramCounter() |
<Plug>VimspectorBalloonEval | Werten Sie den Ausdruck unter dem Cursor (oder visuell) im Popup aus | intern |
Diese stimmen ungefähr 1:1 mit den unten aufgeführten API-Funktionen überein.
Wenn Sie beispielsweise möchten, dass <F5> das Debuggen startet/fortsetzt, fügen Sie dies an einer geeigneten Stelle hinzu, z. B. Ihrem vimrc (Hinweis: run :e $MYVIMRC ).
nmap <F5> <Plug> VimspectorContinueDarüber hinaus möchten viele Benutzer wahrscheinlich nur bestimmte Vimspector-Zuordnungen aktivieren, während das Debuggen aktiv ist. Dies ist auch möglich, erfordert jedoch das Verfassen eines Drehbuchs.
Allerdings sind viele Leute mit bestimmten Debuggern vertraut, sodass die folgenden Zuordnungen aktiviert werden können, indem g:vimspector_enable_mappings auf den angegebenen Wert gesetzt wird.
Um Visual Studio-ähnliche Zuordnungen zu verwenden, fügen Sie Folgendes zu Ihrem vimrc hinzu, bevor Sie vimspector laden :
let g: vimspector_enable_mappings = ' VISUAL_STUDIO '| Schlüssel | Abbildung | Funktion |
|---|---|---|
F5 | <Plug>VimspectorContinue | Fahren Sie beim Debuggen fort. Andernfalls beginnen Sie mit dem Debuggen. |
Shift F5 | <Plug>VimspectorStop | Hören Sie mit dem Debuggen auf. |
Ctrl Shift F5 | <Plug>VimspectorRestart | Starten Sie das Debuggen mit derselben Konfiguration neu. |
F6 | <Plug>VimspectorPause | Debugger anhalten. |
F8 | <Plug>VimspectorJumpToNextBreakpoint | Zum nächsten Haltepunkt in der aktuellen Datei springen. |
Shift F8 | <Plug>VimspectorJumpToPreviousBreakpoint | Zum vorherigen Haltepunkt in der aktuellen Datei springen. |
F9 | <Plug>VimspectorToggleBreakpoint | Zeilenhaltepunkt in der aktuellen Zeile umschalten. |
Shift F9 | <Plug>VimspectorAddFunctionBreakpoint | Fügen Sie einen Funktionshaltepunkt für den Ausdruck unter dem Cursor hinzu |
F10 | <Plug>VimspectorStepOver | Steigen Sie hinüber |
Ctrl F10 | <Plug>VimspectorRunToCursor | Zum Cursor laufen* |
F11 | <Plug>VimspectorStepInto | Treten Sie ein |
Shift F11 | <Plug>VimspectorStepOut | Verlassen Sie den aktuellen Funktionsumfang |
Alt 8 | <Plug>VimspectorDisassemble | Demontage anzeigen |
HINWEIS: Einige Zuordnungen, wie z. B. Strg- und F-Tasten, funktionieren je nach Terminal, Tastatur, Fenstersystem und vielen anderen Dingen möglicherweise nicht. Siehe :help modifyOtherKeys und andere Quellen. Wenn dies nicht funktioniert, verwenden Sie einfach die Zuordnungen im „menschlichen Modus“.
Wenn Sie wie ich nur 2 Hände und 10 Finger haben, mögen Sie wahrscheinlich keine Strg-Umschalt-F-Tasten. Wenn Sie in einem Terminal arbeiten, besteht außerdem die reale Möglichkeit, dass terminfo für Umschalt-F-Tasten falsch ist, insbesondere wenn Ihr TERM screen-256color ist. Wenn diese Probleme (Anzahl der Hände, TERM -Variablen) nicht behoben werden können, versuchen Sie die folgenden Zuordnungen, indem Sie Folgendes hinzufügen, bevor Sie vimspector laden :
let g: vimspector_enable_mappings = ' HUMAN '| Schlüssel | Abbildung | Funktion |
|---|---|---|
F5 | <Plug>VimspectorContinue | Fahren Sie beim Debuggen fort. Andernfalls beginnen Sie mit dem Debuggen. |
F3 | <Plug>VimspectorStop | Hören Sie mit dem Debuggen auf. |
F4 | <Plug>VimspectorRestart | Starten Sie das Debuggen mit derselben Konfiguration neu. |
F6 | <Plug>VimspectorPause | Debugger anhalten. |
F9 | <Plug>VimspectorToggleBreakpoint | Zeilenhaltepunkt in der aktuellen Zeile umschalten. |
<leader>F9 | <Plug>VimspectorToggleConditionalBreakpoint | Schalten Sie den bedingten Zeilenhaltepunkt oder Protokollpunkt in der aktuellen Zeile um. |
F8 | <Plug>VimspectorAddFunctionBreakpoint | Fügen Sie einen Funktionshaltepunkt für den Ausdruck unter dem Cursor hinzu |
<leader>F8 | <Plug>VimspectorRunToCursor | Zum Cursor laufen |
F10 | <Plug>VimspectorStepOver | Steigen Sie hinüber |
F11 | <Plug>VimspectorStepInto | Treten Sie ein |
F12 | <Plug>VimspectorStepOut | Verlassen Sie den aktuellen Funktionsumfang |
Darüber hinaus empfehle ich, im normalen und visuellen Modus eine Zuordnung zu <Plug>VimspectorBalloonEval hinzuzufügen, zum Beispiel:
" 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> VimspectorBalloonEvalMöglicherweise möchten Sie auch Zuordnungen zum Navigieren im Stapel nach oben/unten, zum Umschalten des Haltepunktfensters und zum Anzeigen der Disassemblierung hinzufügen, zum Beispiel:
nmap <LocalLeader> <F11> <Plug> VimspectorUpFrame
nmap <LocalLeader> <F12> <Plug> VimspectorDownFrame
nmap <LocalLeader> B <Plug> VimspectorBreakpoints
nmap <LocalLeader> D <Plug> VimspectorDisassembleIn diesem Abschnitt werden detaillierte Nutzungsanweisungen definiert, die nach Funktion geordnet sind. Für die meisten Benutzer enthält der Abschnitt „Zuordnungen“ die gebräuchlichsten Befehle und Standardverwendungen. Dieser Abschnitt kann als Referenz zum Erstellen eigener Zuordnungen oder benutzerdefinierter Verhaltensweisen verwendet werden.
Alle folgenden Anweisungen gehen von einer einzelnen Debugging-Sitzung aus. Einzelheiten zum Debuggen mehrerer unabhängiger Apps gleichzeitig finden Sie unter [mehrere Debugging-Sitzungen][#multiple-debugging-sessions].
.vimspector.json . Siehe unten.:call vimspector#Launch() und wählen Sie eine Konfiguration aus.Durch das Starten einer neuen Sitzung wird diese zur aktiven [Debugging-Sitzung][#multiple-debugging-sessions].
Wenn die Debug-Adapterkonfiguration pidProperty verwendet und Sie eine attach stellen, werden Sie aufgefordert, eine PID (Prozess-ID) einzugeben, an die angehängt werden soll.
Um dies zu vereinfachen, bietet Vimspector ein kleines Dienstprogramm zum Auflisten von PIDs. Es ist wie ein sehr, sehr einfacher ps -Klon, funktioniert aber auf allen unterstützten Plattformen. Anweisungen zum Einrichten finden Sie in der README-Datei.
Führen Sie go build im Verzeichnis support/vimspector_process_list aus, um es einzurichten.
Wenn Vimspector diese App finden kann, versucht es standardmäßig alle Prozesse aufzulisten, die dem aktuellen Benutzer gehören.
Alternativ (vorzugsweise) können Sie eine spezielle Form der Variablenerweiterung namens ${PickProcess("binaryName")} verwenden. Die Version dieses Aufrufs listet alle Prozesse für den aktuellen Benutzer auf, die diesem Binärnamen entsprechen.
Zum Beispiel:
"Attach" : {
"adapter" : "CodeLLDB" ,
"configuration" : {
"request" : "attach" ,
"program" : "${workspaceRoot}/Jails" ,
"pid" : "${PickProcess("jails")}"
}
}Dadurch werden alle passenden Prozesse, ihr übergeordneter Prozess, ihre Startzeit und ihr Arbeitsverzeichnis aufgelistet. Es sieht ungefähr so aus:
PID PPID CWD START
52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24
Enter Process ID:
Anschließend geben Sie die PID ein und drücken <CR> .
Sie können die Prozessauswahl sogar durch Ihre eigene Funktion ersetzen. Wenn Sie eine Funktion definieren und g:vimspector_custom_process_picker_func auf den Namen dieser Funktion setzen. Es werden alle Argumente übergeben, die an die PickProcess Erweiterungsfunktion übergeben werden. Es wird auch immer dann verwendet, wenn eine pidProperty angegeben wird, daher darf es auch keine Argumente verarbeiten (verwenden Sie ... als formale Argumente für die Funktion, siehe :help ... ).
Um beispielsweise fzf zusammen mit der bereitgestellten vimspector_process_list zu verwenden:
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 ' Oder um fzf mit der Ausgabe von ps zu verwenden:
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 'Um eine bestimmte Debug-Konfiguration zu starten oder Ersatzvariablen für den Start anzugeben, können Sie Folgendes verwenden:
:call vimspector#LaunchWithSettings( dict ) Das Argument ist ein dict mit den folgenden Schlüsseln:
configuration : (optional) Name der zu startenden Debug-Konfiguration<anything else> : (optional) Name einer festzulegenden Variablen Dies ermöglicht eine gewisse Integration und Automatisierung. Wenn Sie beispielsweise eine Konfiguration mit dem Namen Run Test haben, die eine Ersetzungsvariable mit dem Namen ${Test} enthält, könnten Sie eine Zuordnung schreiben, die letztendlich Folgendes ausführt:
vimspector#LaunchWithSettings ( #{ configuration: ' Run Test '
Test: ' Name of the test ' } ) Dies würde die Run Test -Konfiguration starten, wobei ${Test} auf 'Name of the test' gesetzt wäre, und Vimspector würde den Benutzer nicht auffordern, diese Dinge einzugeben oder zu bestätigen.
In unserem YouCompleteMe-Integrationsleitfaden finden Sie ein weiteres Beispiel, in dem damit der Port für die Verbindung mit dem Java-Debugger angegeben werden kann
Zum Starten mit einer Ad-hoc-Konfiguration können Sie Folgendes verwenden:
call vimspector#LaunchWithConfigurations( dict ) Das Argument ist ein dict , das den configurations einer .vimspector-Datei darstellt. Übergeben Sie eine Konfiguration und diese wird als auszuführende Konfiguration ausgewählt. Zum Beispiel:
let pid = <some_expression>
call vimspector#LaunchWithConfigurations ({
" attach " : {
" adapter " : " netcoredbg " ,
" configuration " : {
" request " : " attach " ,
" processId " : pid
}
}
} ) Dadurch wird der Debugger gestartet und an den angegebenen Prozess angehängt, ohne dass eine lokale .vimspector-Datei auf der Festplatte vorhanden sein muss. Die Variable ${workspaceRoot} verweist auf den übergeordneten Ordner der Datei, die derzeit in vim geöffnet ist.
Vimspector verwendet die folgende Logik, um eine zu startende Konfiguration auszuwählen:
autoselect nicht auf false gesetzt ist.default auf true und autoselect nicht auf false festgelegt ist.Einzelheiten finden Sie im Referenzhandbuch.
vimspector#GetConfigurations() um eine Liste der Konfigurationen für den Dateityp des aktuellen Puffers abzurufenBeispielsweise, um eine Reihe von Konfigurationen und Fuzzy-Matching für das Ergebnis zu erhalten
: call matchfuzzy ( vimspector#GetConfigurations (), " test::case_1 " )Im Abschnitt „Zuordnungen“ finden Sie die Standardzuordnungen für die Arbeit mit Haltepunkten. In diesem Abschnitt wird die vollständige API in Vimscript-Funktionen beschrieben.
Haltepunkte sind mit der aktuellen [Debugging-Sitzung][#multiple-debugging-sessions] verknüpft. Beim Wechsel zwischen Sitzungen werden die Haltepunktzeichen für die vorherige Sitzung entfernt und die Haltepunkte für die neu aktivierte Sitzung angezeigt. Obwohl es nützlich sein kann, Haltepunkte für alle Sitzungen anzuzeigen, kann dies sehr verwirrend sein.
Verwenden Sie :VimspectorBreakpoints oder ordnen Sie etwas <Plug>VimspectorBreakpoints zu, um die Haltepunktansicht zu öffnen. Von hier aus können Sie Haltepunkte auflisten, löschen, hinzufügen und umschalten.
Ich empfehle eine Zuordnung wie diese, um das Haltepunktfenster umzuschalten:
nmap <Leader> db <Plug> VimspectorBreakpointsDie folgenden Zuordnungen gelten standardmäßig im Haltepunktfenster:
t , <F9> – umschalten, dh Haltepunkt aktivieren/deaktivierenT – umschalten, dh ALLE Haltepunkte aktivieren/deaktivierendd , <Del> – löscht den aktuellen Haltepunktcc , C – Bearbeiten Sie die aktuellen Haltepunktoptioneni , a , o – einen neuen Zeilenhaltepunkt hinzufügenI , A , O – einen neuen Funktionshaltepunkt hinzufügen<Enter> oder Doppelklick – springen Sie zum ZeilenhaltepunktEine WinBar wird ebenfalls bereitgestellt (sofern unterstützt). Dadurch werden Funktionen wie das Speichern/Wiederherstellen von Sitzungen, das Löschen aller Haltepunkte und das Zurücksetzen der Optionen für Ausnahme-Haltepunkte hinzugefügt.
Die einfachste und gebräuchlichste Form eines Haltepunkts ist ein Zeilenhaltepunkt. Die Ausführung wird angehalten, wenn die angegebene Zeile ausgeführt wird.
In den meisten Debugging-Szenarien drücken Benutzer einfach <F9> um einen Zeilenumbruchpunkt in der aktuellen Zeile zu erstellen, und <F5> um die Anwendung zu starten.
Einige Debug-Adapter unterstützen bedingte Haltepunkte. Beachten Sie, dass vimspector Ihnen nicht mitteilt, ob der Debugger (noch) keine bedingten Haltepunkte unterstützt. Ein bedingter Haltepunkt ist ein Haltepunkt, der nur dann ausgelöst wird, wenn ein Ausdruck „true“ ergibt oder andere Einschränkungen erfüllt sind.
Einige der oben genannten Funktionen benötigen ein einzelnes optionales Argument, bei dem es sich um ein Optionswörterbuch handelt. Das Wörterbuch kann die folgenden Schlüssel haben:
condition : Ein optionaler Ausdruck, der ausgewertet wird, um zu bestimmen, ob der Haltepunkt ausgelöst werden soll. Wird nicht von allen Debug-Adaptern unterstützt. Um beispielsweise zu unterbrechen, wenn abc 10 ist, geben Sie je nach Sprache etwas wie abc == 10 ein.hitCondition : Ein optionaler Ausdruck, der ausgewertet wird, um zu bestimmen, wie oft der Haltepunkt ignoriert werden soll. Sollte (wahrscheinlich?) nicht in Kombination mit condition verwendet werden. Wird nicht von allen Debug-Adaptern unterstützt. Um beispielsweise beim dritten Auftreffen auf diese Linie zu brechen, geben Sie 3 ein.logMessage : Eine optionale Zeichenfolge, um diesen Haltepunkt stattdessen zu einem „Logpoint“ zu machen. Bei Auslösung wird diese Meldung an die Konsole ausgegeben, anstatt die Ausführung zu unterbrechen. Sie können Ausdrücke in geschweiften Klammern einbetten {like this} , zum Beispiel #{ logMessage: "Iteration {i} or {num_entries / 2}" }In jedem Fall werden Ausdrücke vom Debugger ausgewertet und sollten daher bei der Auswertung von Ausdrücken in dem Dialekt vorliegen, den der Debugger versteht.
Bei Verwendung der Zuordnung <leader><F9> wird der Benutzer aufgefordert, diese Ausdrücke in einer Befehlszeile (mit Verlauf) einzugeben.
Ausnahme-Haltepunkte werden normalerweise ausgelöst, wenn eine Ausnahme ausgelöst wird oder eine andere Fehlerbedingung auftritt. Je nach Debugger werden Ihnen beim Starten des Debuggens möglicherweise einige Fragen zum Umgang mit Ausnahmen gestellt. Dies sind „Ausnahme-Haltepunkte“ und Vimspector merkt sich Ihre Auswahl, während Vim noch läuft.
Normalerweise können Sie die Standardeinstellungen akzeptieren (drücken Sie einfach weiter <CR> !), da die meisten Standardeinstellungen für Debug-Adapter sinnvoll sind. Wenn Sie jedoch eine Unterbrechung vornehmen möchten, sagen Sie uncaught exception und antworten Sie dann (zum Beispiel) mit Y “.
Sie können Ihre Auswahl in .vimspector.json konfigurieren. Einzelheiten dazu finden Sie im Konfigurationsleitfaden.
HINWEIS: Bisher wechselte ToggleBreakpoint zwischen drei Zuständen: aktiviert, deaktiviert, gelöscht. Viele Benutzer empfanden den Status „deaktiviert“ als selten nützlich, daher wurde das Verhalten geändert. ToggleBreakpoint erstellt oder löscht immer einen Haltepunkt. Wenn Sie Haltepunkte „deaktivieren“ möchten, verwenden Sie das Haltepunktfenster und „schalten“ ( t ) von dort aus.
vimspector#ToggleBreakpoint( { options dict } ) um einen Zeilenhaltepunkt festzulegen/zu löschen. Das Argument ist optional (siehe unten).vimspector#AddFunctionBreakpoint( '<name>', { options dict} ) um einen Funktionshaltepunkt hinzuzufügen. Das zweite Argument ist optional (siehe unten).vimspector#SetLineBreakpoint( file_name, line_num, { options dict } ) um einen Haltepunkt an einer bestimmten Datei/Zeile festzulegen. Das letzte Argument ist optional (siehe unten)vimspector#ClearLineBreakpoint( file_name, line_num ) um einen Haltepunkt an einer bestimmten Datei/Zeile zu entfernenvimspector#ClearBreakpoints() um alle Haltepunkte zu löschenvimspector#ResetExceptionBreakpoints() um die Konfiguration der Ausnahme-Haltepunkte zu löschen und die verschiedenen Fragen wie „Break on C++ Throw“ erneut zu beantworten.:VimspectorMkSession und :VimspectorLoadSession um Haltepunkte zu speichern und wiederherzustellencall vimspector#ListBreakpoints() – Haltepunktfenster umschaltencall vimspector#BreakpointsAsQuickFix() – gibt den aktuellen Satz von Haltepunkten im Vim-Quickfix-Format zurückBeispiele:
call vimspector#ToggleBreakpoint() – Haltepunkt in der aktuellen Zeile umschaltencall vimspector#SetLineBreakpoint( 'some_file.py', 10 ) – setze einen Haltepunkt auf some_filepy:10call vimspector#AddFunctionBreakpoint( 'main' ) – Fügen Sie einen Funktionshaltepunkt zur main hinzucall vimspector#ToggleBreakpoint( { 'condition': 'i > 5' } ) – fügt einen Haltepunkt in der aktuellen Zeile hinzu, der nur ausgelöst wird, wenn i > 5 true istcall vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i > 5' } ) – füge einen Haltepunkt bei some_file.py:10 hinzu, der nur ausgelöst wird, wenn i > 5 true istcall vimspector#ClearLineBreakpoint( 'some_file.py', 10 ) – lösche den Haltepunkt bei some_file.py:10call vimspector#ClearBreakpoints() – alle Haltepunkte löschenVimspectorMkSession – .vimspector.session erstellenVimspectorLoadSession – .vimspector.session lesenVimspectorMkSession my_session_file – erstellt my_session_fileVimspectorLoadSession my_session_file – liest my_session_fileHINWEIS : Experimentelle Funktion, die sich aufgrund des Benutzerfeedbacks in Zukunft erheblich ändern kann.
Befehlshaltepunkte können aus dem Disassemblierungsfenster auf die gleiche Weise hinzugefügt werden, wie Sie Zeilenhaltepunkte im Codefenster hinzufügen. Für das Hinzufügen und Umschalten gelten dieselben Zuordnungen und Funktionen. Sofern vom Debug-Adapter unterstützt, können Sie auf diese Weise sogar Protokollpunkte und bedingte Haltepunkte erstellen.
Derzeit werden die Haltepunkte für Anweisungen intern als Zeilenbestandspunkte gegen den Puffer modelliert, der die Demontage enthält. Dies kann sich jedoch in Zukunft ändern. Bitte verlassen Sie sich also nicht darauf.
Der Anweisungsbestandteile ist ebenfalls sichtbar und kann aus dem Schalterwesen gelöscht/deaktiviert werden.
Derzeit werden Anleitungsbestandteile automatisch gelöscht, wenn die Debug -Sitzung endet. Der Grund dafür ist, dass die Adressen nicht garantiert für eine andere Debug -Sitzung garantiert werden können. Dies kann sich jedoch auch in Zukunft ändern.
Verwenden Sie vimspector#ClearBreakpoints() um alle Haltepunkte einschließlich des Speicheres der Ausnahmebestandungspunkte zu löschen.
Verwenden Sie vimspector#RunToCursor oder <leader><F8> : Dies erstellt einen vorübergehenden Haltepunkt in der aktuellen Zeile und setzt die Ausführung fort und löscht den Haltepunkt, wenn er getroffen wird.
Verwenden Sie vimspector#GoToCurrentLine() oder eine Zuordnung zu <Plug>VimspectorGoToCurrentLine um die aktuelle Ausführung in die Linie zu überspringen, auf der Ihr Cursor derzeit ist.
Wenn dies unterstützt wird, kann dies nützlich sein, um Abschnitte des Codes neu zu betreiben oder sie vollständig zu überspringen.
Wenn in der aktuellen Zeile mehrere mögliche "Ziele" vorhanden sind, werden Sie aufgefordert, eine auszuwählen.
Vimspector kann Breakpoints (und einige andere Dinge) in einer Sitzungsdatei speichern und wiederherstellen. Dafür gibt es folgende Befehle:
VimspectorMkSession [file/dir name] - Speichern Sie die aktuellen Satz von Zeilenbestandteilen, Logpoints, bedingten Haltepunkten, Funktionsbestandteilen und Ausnahmebrechpoint -Filtern für die angegebene Sitzungsdatei oder die Standarddatei im angegebenen Verzeichnis.VimspectorLoadSession [file/dir name] - Lesen Sie den Haltepunkte aus der gelieferten Sitzungsdatei oder in der Standarddatei im angegebenen Verzeichnis und ersetzen Sie alle derzeit festgelegten Haltepunkte. Vor dem Laden werden alle aktuellen Breakpoints gelöscht (als ob vimspector#ClearLineBreakpoints() aufgerufen würde). In beiden Fällen ist das Argument "Datei/Dire Name" optional. Standardmäßig heißt die Datei .vimspector.session genannt, kann jedoch global geändert werden, indem g:vimspector_session_file_name auf etwas anderes festgelegt oder durch manuelles Angeben eines Pfades beim Aufrufen des Befehls. Wenn Sie ein Verzeichnis angeben, wird der Standard- oder Konfigurationssitzungsname für dieses Verzeichnis gelesen oder in dieses Verzeichnis geschrieben. Auf anderen wird die Datei basierend auf dem aktuell geöffneten Puffer gelesen oder in das aktuelle Arbeitsverzeichnis geschrieben.
Erweiterte Benutzer möchten möglicherweise den Prozess des Ladens und Speicherns automatisieren, beispielsweise durch Hinzufügen VimEnter und VimLeave -Autokommandien. Es wird in diesem Fall empfohlen, silent! Um ärgerliche Fehler zu vermeiden, wenn die Datei nicht gelesen oder geschrieben werden kann.
Die einfachste Form der Automatisierung besteht darin, die Vimspector -Sitzung zu laden, wenn Sie VIM mit einer Sitzungsdatei starten. Dies ist so einfach wie dies:
$ echo silent VimspectorLoadSession > Sessionx.vim
Siehe :help mksession für Details zur *x.vim -Datei. Sie können so etwas auch mit SessionLoadPost tun:
autocmd SessionLoadPost * silent ! VimspectorLoadSessionvimspector#StepInto() usw. Es gibt auch vimspector#StepSOver() und vimspector#StepIOver() usw. Varianten für die Anweisung bzw. Anweisungen Granularität. <CR> oder doppelklicken Sie mit der linken Maus zum Erweitern/Zusammenbruch (+, -).<C-CR> (Steuerung + <CR> ) oder <leader><CR> fest (wenn modifyOtherKeys für Sie nicht funktioniert) Scopes und Variablen werden vom Puffer vimspector.Variables dargestellt.
Wenn Sie eine ausführlichere Anzeige für Variablen und Uhren bevorzugen, können Sie let g:vimspector_variables_display_mode = 'full' . Standardmäßig werden nur der Name und Wert angezeigt, wobei andere Daten, die aus der Maus oder dem Auslösen von <Plug>VimspectorBalloonEval verfügbar sind, in der Zeile, die den Wert in den Variablen (oder Uhren) Fenster enthält, überfliegen.
Alle Regeln für Variables and scopes gelten plus Folgendes:
a + b ) durchzuführen und sein Ergebnis zu erhalten.nmap ) und einen visuellen Modus ( xmap ) zu <Plug>VimspectorBalloonEval , um das Popup manuell auszulösen.<C-CR> (Steuerung + <CR> ) oder <leader><CR> fest (wenn modifyOtherKeys für Sie nicht funktioniert)j , k ), um die aktuelle Auswahl auszuwählen. <Esc> (oder lassen Sie das Tooltip -Fenster), um den Tooltip zu schließen. Sie können das automatische schwebende Popup durch Einstellungen g:vimspector_enable_auto_hover=0 deaktivieren, bevor Sie die Debug -Sitzung starten. Sie können dann etwas auf <Plug>VimspectorBalloonEval zuordnen und manuell auslösen.
Das Uhrfenster wird verwendet, um Variablen und Ausdrücke zu inspizieren. Ausdrücke werden im ausgewählten Stapelrahmen bewertet, der sich "fokussiert" hat
Das Fenster des Uhren ist ein promptierter Puffer, wo das verfügbar ist. Geben Sie den Einfügenmodus ein, um einen neuen Uhrenausdruck hinzuzufügen.
<CR> verpflichten.:VimspectorWatch <expression> . In einigen Debug-Adaptern ist die Registerkarte für den Ausdruck für den Ausdruck verfügbar.<CR> oder doppelklicken Sie mit der linken Maus.<C-CR> (Steuerung + <CR> ) oder <leader><CR> fest (wenn modifyOtherKeys für Sie nicht funktioniert)<DEL> . Die Uhren werden vom Buffer vimspector.Watches dargestellt.
Wenn Sie eine ausführlichere Anzeige für Variablen und Uhren bevorzugen, können Sie let g:vimspector_variables_display_mode = 'full' . Standardmäßig werden nur der Name und Wert angezeigt, wobei andere Daten, die aus der Maus oder dem Auslösen von <Plug>VimspectorBalloonEval verfügbar sind, in der Zeile, die den Wert in den Variablen (oder Uhren) Fenster enthält, überschreiten.
Sie können das automatische schwebende Popup durch Einstellungen g:vimspector_enable_auto_hover=0 deaktivieren, bevor Sie die Debug -Sitzung starten. Sie können dann etwas auf <Plug>VimspectorBalloonEval zuordnen und manuell auslösen.
Der Watch -Eingabeaufforderungspuffer hat seinen omnifunc auf eine Funktion eingestellt, die die Fertigstellung für den aktuellen Ausdruck berechnet. Dies wird trivial mit <Ctrl-x><Ctrl-o> (siehe :help ins-completion ) verwendet oder in Ihr bevorzugter Abschlusssystem integriert. Der Filetyp im Puffer ist auf VimspectorPrompt eingestellt.
Für YouCompleteme funktioniert die folgende Konfiguration gut:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}:VimspectorDisassemble , vimspector#ShowDisassembly() oder <Plug>VimspectorDisassembleEinige Debug -Adapter (wenige!) Unterstützen die Demontage. Die Art und Weise, wie dies in DAP funktioniert, ist ein wenig sprecher, aber in der Praxis wird Vimspector bitten, eine Reihe von Anweisungen rund um den PC des aktuellen Stack -Rahmens zu zerlegen. Dies wird dann in einem Fenster mit einer Winbar angezeigt, die dem Codefenster ähnelt, jedoch mit einer Anweisung, die Granularität steigt. Es gibt ein Zeichen für die aktuelle Anweisung und die Syntax -Hochstände standardmäßig für "ASM", das für X86 und ARM meistens in Ordnung ist.
Wie oben erwähnt, wird das Treten automatisch eher <F10> auf eine pro-intition als pro Anweisung.
Jedes Mal, wenn der Prozess stoppt, fordert Vimspector etwa 2 Fenster mit Anweisungen rund um den aktuellen PC an. Um mehr zu sehen, können Sie das Fenster scrollen. Vimspector wird in einem zusätzlichen Bildschirm mit Anweisungen eingestellt, wenn das Fenster oben oder in der Nähe von unten scrollt. Das ist nicht perfekt. Manchmal muss man ein bisschen mehr scrollen, um es Seite zu machen (z. B. STRL-E-STRG-y oben). Dies ist nicht ideal und kann in Zukunft verbessert werden.
Sie können die intielle Höhe des Demontagefensters mit let g:vimspector_disassembly_height = 10 (oder Whatver -Anzahl von Zeilen) steuern.
Der Filetyp (und die Syntax) der Puffer im Demontagefenster ist vimspector-disassembly . Sie können FileType AutoCommands verwenden, um Dinge wie die Syntax -Hervorhebung anzupassen.
HINWEIS : Diese Funktion ist experimentell und kann sich in irgendeiner Weise basierend auf dem Feedback der Benutzer ändern.
Einige Debug -Adapter bieten eine Möglichkeit, den Prozessspeicher, der mit Variablen verbunden ist, abzugeben. Dies kann aus den Variablen erfolgen und schauen Windows mit:
<leader>m Mapping (standardmäßig kann angepasst werden)vimspector#ReadMemory() Funktion Auf diese Weise werden Sie aufgefordert, eine Reihe von Bytes (aus dem mit der aktuellen Cursorlinie verknüpften Standort) und einen Offset von diesem Ort einzugeben. In dem Codefenster wird ein neuer Puffer angezeigt, der einen Speichermüll in Hex und ASCII enthält, ähnlich der Ausgabe von xxd .
HINWEIS : Diese Funktion ist experimentell und kann sich in irgendeiner Weise basierend auf dem Feedback der Benutzer ändern.
Das Stack Trace -Fenster zeigt den Status jedes Programms an. Die gestoppten Themen können erweitert werden, um die Stapelspur dieses Threads anzuzeigen.
Oft, aber nicht immer, werden alle Threads gestoppt, wenn ein Haltepunkt getroffen wird. Der Status eines Threads wird nach dem Namen des Threads in Klammern angezeigt. Wo von dem zugrunde liegenden Debugger unterstützt werden, können Fäden in der Stapelspurfenster ausgehalten und individuell fortgesetzt werden.
Ein bestimmter Faden, der mit der CursorLine -Highlight -Gruppe hervorgehoben wird, ist der "fokussierte" Faden. Dies ist der Thread, der Befehle wie "Schritt in", "Schritt aus", "Weiter" und "Pause" im Codefenster empfängt. Der fokussierte Faden kann manuell in "Umschalten" zu diesem Thread geändert werden.
<CR> oder doppelklicken Sie mit der linken Maus, um eine Fadenstapelverfolgung zu erweitern/zusammenzubrechen, oder verwenden Sie die Winbar-Taste.<CR> oder doppelklicken Sie mit der linken Maus auf einem Stapelrahmen, um darauf zu springen.vimspector#PauseContinueThread() um den ausgewählten Thread einzeln zu pausieren oder fortzusetzen.<leader><CR> oder vimspector#SetCurrentThread() um den "fokussierten" Thread auf den aktuell ausgewählten zu setzen. Wenn die ausgewählte Zeile ein Stapelrahmen ist, stellen Sie den fokussierten Thread auf den Thread dieses Frame ein und springen Sie zu diesem Frame im Codefenster. Die Stapelspur wird durch den Buffer vimspector.StackTrace dargestellt.
Wenn es Kinder-Debug-Sitzungen gibt, beispielsweise bei der Start des Debugee und des Debug-Adapters unterstützt das Debugging von mehreren Sitzungen, dann werden die Threads jeder Sitzung getrennt angezeigt. Die aktuell aktive Sitzung ist diejenige, die als aktuell aktiver Thread/Stack -Frame hervorgehoben wird. Um die Steuerung auf eine andere Sitzung zu wechseln, konzentrieren Sie sich in dieser Sitzung einen Thread.
Hinweis: Dies bezieht sich auf Sitzungen, die als Kinder einer vorhandenen Sitzung erstellt wurden, und darf nicht mit [mehreren (übergeordneten) Debugging-Sitzungen] [#Multiple-Debugging-Sessions] verwechselt werden.
:VimspectorShowOutput <category> . Verwenden Sie die Befehlszeilenabschluss, um die Kategorien anzuzeigen. Wenn das Ausgangsfenster geschlossen ist, kann ein neues mit :VimspectorShowOutput <category> geöffnet werden (Verwenden Sie die Registerkarte - wildmenu , um die Optionen anzuzeigen).
Das Konsolenfenster ist ein promptierter Puffer, in dem dies verfügbar ist, und kann als interaktiver CLI für den Debug -Adapter verwendet werden. Die Unterstützung dafür variiert zwischen Adaptern.
:VimspectorEval <expression> . Die Fertigstellung ist mit einigen Debug -Adaptern erhältlich.<CR>Hinweis: Siehe auch Uhren oben.
Wenn das Ausgangsfenster geschlossen ist, kann eine neue mit :VimspectorShowOutput Console geöffnet werden.
Der Konsolen -Eingabeaufforderungspuffer hat seinen omnifunc auf eine Funktion festgelegt, die die Fertigstellung für den aktuellen Befehl/den aktuellen Ausdruck berechnet. Dies wird trivial mit <Ctrl-x><Ctrl-o> (siehe :help ins-completion ) verwendet oder in Ihr bevorzugter Abschlusssystem integriert. Der Filetyp im Puffer ist auf VimspectorPrompt eingestellt.
Für YouCompleteme funktioniert die folgende Konfiguration gut:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}Die Vimspector -Protokolldatei enthält eine vollständige Verfolgung der Kommunikation zwischen Vimspector und dem Debug -Adapter. Dies ist die Hauptquelle für diagnostische Informationen, wenn etwas schief geht, das kein Vim -Traceback ist.
Wenn Sie nur die Vimspector -Protokolldatei sehen möchten, verwenden Sie :VimspectorToggleLog , das sie in einem kleinen Fenster verkleinert (funktioniert nicht unter Windows).
Sie können einige Debugging -Informationen sehen mit :VimspectorDebugInfo
Um den Debugger zu schließen, verwenden Sie:
Reset:VimspectorReset Wenn die Winbar nicht verfügbar ist.call vimspector#Reset()Wenn das Debuggee beim Anhalten oder Zurücksetzen noch läuft, können Sie angeben, was beim Beenden des Debuggens passieren soll. Normalerweise ist das Standardverhalten sinnvoll, und genau das passiert die meiste Zeit. Dies sind die Standardeinstellungen nach DAP:
Einige Debug -Adapter ermöglichen es Ihnen, zu wählen, was zu tun ist, wenn Sie die Verbindung tun. Wenn Sie dieses Verhalten kontrollieren möchten, verwenden Sie :VimspectorReset oder rufen Sie vimspector#Reset( { 'interactive': v:true } ) . Wenn der Debug -Adapter die Wahl bietet, ob das Debuggee beendet werden soll oder nicht, werden Sie zur Auswahl aufgefordert. Gleiches gilt für vimspector#Stop() das ein Argument aufnehmen kann: vimspector#Stop( { 'interactive': v:true } ) .
Hinweis : Diese Funktion ist experimentell und jeder Teil davon kann sich als Reaktion auf das Feedback der Benutzer ändern.
Vimspector unterstützt eine willkürliche Anzahl von Debug -Sitzungen. Jede Sitzung ist einer einzelnen Registerkarte UI zugeordnet. Normalerweise debuggen Sie nur eine einzige App und müssen daher nicht darüber nachdenken. Diese erweiterte Funktion kann jedoch nützlich sein, wenn Sie gleichzeitig mehrere, unabhängige Anwendungen oder mehrere unabhängige Instanzen Ihrer Anwendung debuggen müssen.
Zu jeder Zeit gibt es eine einzige "aktive" Stammsitzung. Breakpoints sind der aktuellen Sitzung zugeordnet, und alle UI- und API -Befehle werden auf die aktuell aktive Sitzung angewendet.
Beim Umschalten zwischen Root -Sitzungen werden die Breakpont -Zeichen für die vorherige Sitzung entfernt und die Haltepunkte für die neu aktivierte Sitzung angezeigt. Obwohl es nützlich sein könnte, Breakpoints für alle Sitzungen zu sehen, kann dies sehr verwirrend sein.
Ein typischer Workflow könnte sein:
:edit server.cc , dann <F5> ). Dies startet eine Debug -Sitzung, die nach der ausgewählten Konfiguration benannt ist. Sie könnten es umbenennen :VimspectorRenameSession server .:tabedit client.cc ).client :: :VimspectorNewSession client ( client ist jetzt die aktive Sitzung).client einen Haltepunkt hinzu und beginnen Sie mit <F5> . Sie haben jetzt 2 Vimspector -Registerkarten. Intuitiv wird wwitching auf eine bestimmte Registerkarte seine Sitzung aktiv machen. Sie können die aktive Sitzung auch manuell wechseln mit :VimspectorSwitchToSession <name> .
Zusammenfassend haben Sie die folgenden Einrichtungen:
VimspectorNewSession <name> Dies schafft eine neue Sitzung und macht sie aktiv. Optionaler Name wird anstelle des generierten Erzeugers beim Start eines Starts verwendet.VimspectorSwitchToSession <tab complete> .VimspectorRenameSession <new name>VimspectorDestroySession <name> manuell zerstören (wenn Sie mutig sind). Sie können keine laufende/aktive Sitzung zerstören.vimspector#GetSessionName() nützlich, um eine Statuslinie einzuführen. Es gibt auch vimspector#GetSessionID() für Technikern. Hier ist ein Beispiel dafür, wie Sie den aktuellen Sitzungsnamen in der statusline anzeigen können (siehe :help statusline oder die Dokumentation für Ihr ausgefallenes Statuszeilen -Plugin).
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 ()} % ) Eine Einführung in die Konfiguration von .vimspector.json finden Sie im Abschnitt "Erste Schritte" der Vimspector -Website.
Eine vollständige Erklärung, einschließlich der Verwendung von Variablen, Substitutionen und der Angabe von Ausnahmebestandten, finden Sie in den Dokumenten.
Die JSON-Konfigurationsdatei ermöglicht Kommentare im C-Stil:
// comment to end of line .../* inline comment ... */Derzeit mit den folgenden Debug -Adaptern getestet.
Beispiel .vimspector.json (funktioniert sowohl mit vscode-cpptools als auch lldb-vscode . Für lldb-vscode Ersetzen Sie den Namen des Adapters durch 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> "
}
}
// ...
}
} Hinweis für Windows -Benutzer: Sie müssen gdb.exe installieren. Ich empfehle die Verwendung von scoop install gdb . Vimspector kann den Visual Studio -Debugger wegen Lizenzierung nicht verwenden.
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
"stopAtEntry" : true
}
}
}
}Abhängig vom Backend müssen Sie den hübschen Druck komplexer Typen manuell ermöglichen.
LLDB: Der hübsche Druck ist standardmäßig aktiviert
GDB: Um GDB Pretty Drucker zu ermöglichen, betrachten Sie den Snippet unten. Es reicht nicht aus set print pretty on zu haben!
{
"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
}
]
}
}
}
} In der CPPTools -Dokumentation wird beschrieben, wie CPPTools mit miDebuggerAddress an GDBServer angehängt werden. Beachten Sie, dass Sie bei diesem Fall die "request": "attach" .
Wenn Sie sich schick fühlen, lesen Sie den Referenzhandbuch, um ein Beispiel dafür zu erhalten, dass Vimspector aus der Ferne starten und anhängen.
CodellDB ist VSCODE-CPPTOOLS zumindest auf MacOS überlegen.
Siehe Rost.
Eine Alternative besteht darin, lldb-vscode zu verwenden, das mit LLVM ausgestattet ist. So geht's:
brew install llvm )/path/to/vimspector/gadgets/macos/.gadgets.d/lldb-vscode.json : {
"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 "
}
}
} Rust wird von jedem Debugger mit Basis von GDB/LLDB unterstützt. So funktioniert es gut mit vscode-cpptools und lldb-vscode oben. Die Unterstützung für Rust ist jedoch am besten in 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" - dies ist ungültig. Verwenden Sie stattdessen "request": "launch", "custom": true . Weil Gründecargo erfolgt im VSCODE JavaScript Madness und wird nicht unterstützt."request": custom ; Sehen Sie den Punkt über den oben genannten "benutzerdefinierten" Start anstep-into für Standardbibliotheksfunktionen) kann durch Hinzufügen von "sourceMap": { "from_path" : "to_path" } durchgeführt werden. "from_path" kann im Demontagefenster gefunden werden, indem Sie in der Stapelspur nach oben gehen. "to_path" ist nur Ihr lokal installierter Standardbibliotheksweg für aktuelle Toolchain. Jai Debugging funktioniert einwandfrei mit einem der anderen einheimischen Debugger. Ich empfehle CodellDB, aber Cpptools funktioniert auch.
Beispiel:
{
"$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
Installieren Sie mit install_gadget.py --enable-python oder :VimspectorInstall debugpy , benötigt idealerweise einen Arbeitskompiler und die Python Development Headers/Libs, um eine C-Python-Erweiterung für die Leistung zu erstellen.
HINWEIS : Debugpy unterstützt Python nicht mehr 2. Um weiterhin Python 2-Anwendungen zu debuggen, verwenden Sie den debugpy-python2 Adapter nach der Installation des debugpy-python2 Gadgets.
Vollständige Optionen: 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> "
}
}
...
}
}Um das Remote -Debugging mit Debugpy zu verwenden, müssen Sie Vimspector direkt mit der Debugged -Anwendung verbinden. Dies ist einfach, aber es unterscheidet sich ein wenig von der Art und Weise, wie wir Dinge normalerweise konfigurieren. Insbesondere müssen Sie:
--listen an. Einzelheiten finden Sie in der Debugpy -Dokumentation.{
"configurations" : {
"Python Attach" : {
"adapter" : " multi-session " ,
"filetypes" : [ " python " ], // optional
"configuration" : {
"request" : " attach " ,
"pathMappings" : [
// mappings here (optional)
]
}
}
}
} Einzelheiten zur Startkonfiguration finden Sie unter Erläuterung von Dingen wie pathMappings .
Zusätzliche Dokumentation, einschließlich des Aufenthalts, wenn der Remote -Computer nur über SSH kontaktiert werden kann, werden von Debugpy bereitgestellt.
Wenn Sie sich schick fühlen, sehen Sie sich den Referenzhandbuch an, um ein Beispiel dafür zu erhalten, dass Vimspector aus der Ferne starten und anhängen.
Um weiterhin Python 2-Anwendungen zu debuggen, stellen Sie sicher, dass Sie das debugpy-python2 Gadget (z. B. --force-enable-python2 oder :VimspectorInstall debugpy-python2 ) installieren und dann Ihre Konfiguration ändern, um zu verwenden:
{
"configurations" : {
"Python Attach" : {
"adapter" : " debugpy-python2 " ,
// ...
}
}
}
zum Überblick
Anweisungen finden Sie in meiner Gabel von TclProdebug.
Installation mit install_gadget.py --force-enable-csharp oder :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" : {}
}
}
}
}Erfordert:
install_gadget.py --enable-go or :VimspectorInstall delvego 1.16 oder später (YMMV auf frühere Versionen)Dadurch wird der DAP -Support verwendet, der in den Delve -Debugger eingebaut ist
{
"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 "
}
}
}
}Verwenden Sie Variablen, um Folgendes zu konfigurieren:
dlvFlags : (String) Zusätzliche Befehlszeilenargumente zum Übergeben an DeckungDer Debugger (Delve) wird in einem Terminalfenster gestartet, damit Sie die Ausgabe sehen und die Eingabe an das Debuggee übergeben können.
In VSCODE-GO-Dokumenten finden Sie vollständige Startoptionen. Ja, es scheint, dass dies der einzige Ort ist, an dem sie dokumentiert sind (anscheinend werden sie nicht von Deckt selbst dokumentiert).
Die VSCODE-Go-Dokumente haben auch nützliche Informationen zur Fehlerbehebung
Erfordert:
install_gadget.py --enable-go oder :VimspectorInstall vscode-gogo get -u github.com/go-delve/delve/cmd/dlvdlvToolPath Start anHinweis: Vimspector verwendet den "Legacy" VSCODE-GO-Debug-Adapter und nicht den "integrierten" DAP-Support in Deck. Sie können Nr. 186 dafür verfolgen.
{
"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" ]
}
}
}
}In den VSCODE-GO-Dokumenten finden Sie Informationen zur Fehlerbehebung
Damit werden die Php-Debug verwendet
Erfordert:
install_gadget.py --force-enable-php oder :VimspectorInstall vscode-php-debug zend_extension =xdebug.so
xdebug.remote_enable =on
xdebug.remote_handler =dbgp
xdebug.remote_host =localhost
xdebug.remote_port =9000 Ersetzen Sie localhost durch die IP Ihrer Workstation.
faule Alternative
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
}
}
}
} append XDEBUG_SESSION_START=xdebug an Ihre Abfragebarstellung
curl "http://localhost?XDEBUG_SESSION_START=xdebug"
oder verwenden Sie die zuvor erwähnte XDEBUG -Helfer -Erweiterung (die ein XDEBUG_SESSION -Cookie festlegt)
export XDEBUG_CONFIG= " idekey=xdebug "
php < path to script > Dies verwendet VSCODE-JS-Debug, den Debugger, der auch in VSCODE verwendet wird. Weitere Konfigurationen finden Sie in der Dokumentation hier.
Um VSCODE-JS-DEBUG zu installieren, führen Sie VimspectorInstall vscode-js-debug aus VIM aus oder führen Sie das Installationskript install install_gadget.py --force-enable-node aus. Es gibt mehrere Beispiele, die Sie überprüfen können. Finden Sie sie unter support/test/node/simple , support/test/node/multiprocess und support/test/node/typescript . Eine typische Konfiguration zum Debuggen von Typenkript sieht folgt aus:
{
"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 unterstützt eine Reihe verschiedener "Typen" und kann einige Dinge tun, die möglicherweise funktionieren oder nicht. Das Feld type ist leider nicht dokumentiert, aber die gültigen Werte werden hier im Debugype Enum definiert.
Vimspector wurde nur mit pwa-node -Typ getestet.
Beachten Sie auch, dass dieser Debug -Adapter uns aus irgendeinem Grund immer dazu zwingt, mehrere Debug -Sitzungen zu beginnen. Für einen Benutzer sollte dies nichts ändern (außer vielleicht eine etwas verwirrende Stapelspur). Aber es macht die Dinge komplizierter und kann subtile Fehler geben.
Dies verwendet den Chrome/Firefox-Debugger (sie sind sehr ähnlich), siehe https://marketplace.visualstudio.com/items?itemname=msjsdiag.debugger-for-chrome und https://marketplace.visualstudio.com/items?itemname = Firefox-devtools.vscode-firefox-debug.
Sie können Skripte debuggen, die in Chrome aus innerhalb von VIM ausgeführt werden.
./install_gadget.py --force-enable-chrome oder :VimspectorInstall debugger-for-chrome./install_gadget.py --force-enable-firefox oder :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 arbeitet gut mit dem Java -Debug -Server zusammen, der als JDT.LS -Plugin (Java Language Server) statt als eigenständiger Debug -Adapter ausgeführt wird.
Vimspector ist nicht im Geschäft von Sprachservern, nur Debug -Adapter. Dies bedeutet, dass Sie ein kompatibles Sprachserver -Protokoll -Editor -Plugin benötigen, um Java zu verwenden. Ich empfehle YouCompleteme, das jdt.ls voll unterstützt und vor allem eine triviale Möglichkeit, den Debug -Adapter zu laden und ihn mit Vimspector zu verwenden.
Bei der Verwendung des Java -Debug -Servers unterstützt Vimspector den Hot Code Ersatz für benutzerdefinierte Funktionen. Wenn sich die zugrunde liegenden Klassendateien ändern, fragt Vimspector den Benutzer, ob er diese Klassen zur Laufzeit neu laden möchte.
Dieses Verhalten kann angepasst werden:
let g:vimspector_java_hotcodereplace_mode = 'ask' - Die Standardeinstellung, fragen Sie den Benutzer nach jeder Reload.let g:vimspector_java_hotcodereplace_mode = 'always' - nicht fragen, immer neu ladenlet g:vimspector_java_hotcodereplace_mode = 'never' - Nicht fragen, niemals neu ladeninstall_gadget.py --force-enable-java <other options...> oder :VimspectorInstall java-debug-adaptervscode-java Adapter, z. B.: {
"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> sein, kein spezifischer Adapter. zB in .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> , um den Debug -Server zu starten und Vimspector, z. B. in ~/.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>
Sie können dann <Leader><F5> verwenden, um zu beginnen, nicht nur <F5> zu debuggen.
Wenn Sie "DAP -Port nicht erhalten :YcmCompleter ExecuteCommand vscode.java.startDebugSession ? Ist Jdt.ls initialisiert?" Wenn Sie einen Fehler wie ResponseFailedException: Request failed: -32601: No delegateCommandHandler for vscode.java.startDebugSession , stellen Sie sicher, dass:
g:ycm_java_jdtls_extension_path wird in .vimrc oder vor dem YCM -Start eingestelltDie Startargumente finden Sie im VSCODE -Dokument.
Weitere Informationen finden Sie in diesem Problem.
Lua wird durch lokale LUA-Debugger-VSCODE unterstützt. Dieser Debugger verwendet STDIO, um mit dem laufenden Prozess zu kommunizieren. Aufrufe bei io.read verursachen Probleme.
./install_gadget.py --enable-lua :VimspectorInstall local-lua-debugger-vscodesupport/test/lua/simple und 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} " ]
}
}
}
}Es gibt nur sehr begrenzte Unterstützung für die Anpassung der Benutzeroberfläche.
Vimsector verwendet die folgenden Zeichen intern. Wenn sie definiert sind, bevor Vimsector sie verwendet, werden sie nicht ersetzt. Um die Zeichen anzupassen, definieren Sie sie in Ihrem vimrc .
| Zeichen | Beschreibung | Priorität |
|---|---|---|
vimspectorBP | Linienbrandbezeichnung | 9 |
vimspectorBPCond | Bedingter Linienbestand | 9 |
vimspectorBPLog | Logpoint | 9 |
vimspectorBPDisabled | Behinderte Breakpoint | 9 |
vimspectorPC | Programmzähler (dh aktuelle Linie) | 200 |
vimspectorPCBP | Programmzähler und Haltepunkt | 200 |
vimspectorNonActivePC | Programmzähler für nicht fokussierten Thread | 9 |
vimspectorCurrentThread | Fokussierter Faden in der Stapelspuransicht | 200 |
vimspectorCurrentFrame | Aktueller Stapelrahmen in der Stapelspuransicht | 200 |
Die Standardsymbole entsprechen etwas wie folgt:
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 Wenn die Schilder nicht richtig angezeigt werden, enthält Ihre Schrift diese Glyphen wahrscheinlich nicht. Sie können sie leicht ändern, indem Sie das Zeichen in Ihrem VIMRC definieren. Sie können dies beispielsweise in Ihr vimrc einfügen, um einige einfache ASCII -Symbole zu verwenden:
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 Viele verschiedene Plugins bieten Zeichen für verschiedene Zwecke. Beispiele hierfür sind Diagnosezeichen für Codefehler usw. VIM liefert nur eine einzige Priorität, um zu bestimmen, welches Vorzeichen angezeigt werden sollte, wenn mehrere Vorzeichen in einer einzigen Zeile platziert werden. Wenn Sie feststellen, dass andere Anzeichen Vimspectors (oder umgekehrt) stören, können Sie die von Vimspector verwendete Priorität anpassen, indem Sie das folgende Wörterbuch festlegen:
let g: vimspector_sign_priority = {
' <sign-name> ' : <priority> ,
}Zum Beispiel:
let g: vimspector_sign_priority = {
' vimspectorBP ' : 3 ,
' vimspectorBPCond ' : 3 ,
' vimspectorBPLog ' : 3 ,
' vimspectorBPDisabled ' : 3 ,
' vimspectorNonActivePC ' : 3 ,
' vimspectorPC ' : 999 ,
' vimspectorPCBP ' : 999 ,
}Alle Schlüssel sind optional. Wenn ein Zeichen nicht angepasst wird, wird die von es verwendete Standardpriorität (wie oben gezeigt).
Siehe :help sign-priority . Die Standardpriorität beträgt 10, größere Zahlen überschreiben kleinere.
HINWEIS : Das Standard vimspectorNonActivePC -Zeichen fügt der Signalspalte keinen Text hinzu. Es fügt einfach ein Zeilen -Highlight hinzu, sodass Sie die Zeilen sehen können, in denen andere Threads oder Prozesse derzeit gestoppt werden. Infolgedessen sollte dieses Zeichen normalerweise mit jedem Zeichen verschmelzen , das ein Symbol hinzufügt (z. B. ein Breakpoint -Zeichen). VIM fusioniert nur die Eigenschaften von Zeichen mit der gleichen Priorität. Wenn Sie also die Standardprioritäten ändern, wird empfohlen:
vimspectorBP , vimspectorBPCond usw.) haben die gleiche Priorität.vimspectorNonActivePC -Signal der gleichen Priorität festgelegtvimspectorPC , vimspectorPCBP usw.) hat eine höhere Priorität. Hinweis: Dieser Anpassungspunkt ist derzeit nicht abfallend und kann sich jederzeit ändern.
Manchmal liefert der Debug -Adapter Hinweise darauf, wie die Benutzeroberfläche bestimmte Dinge anzeigen soll. Dies beinhaltet Stackrahmen, Variablen usw.
Vimspector bietet eine einfache Möglichkeit, die angezeigte Anpassung anzupassen, indem Werte im Wörterbuch g:vimsepctor_presentation_hint_hl festgelegt werden.
Die folgenden Schlüssel werden mit der genannten Standard -Highlight -Gruppe unterstützt.
| Gruppe | Schlüssel | Verwendung | Standard |
|---|---|---|---|
| alle | normal | Alles, was nicht unten abgedeckt ist | Normal |
| Stapelspur | emphasize | betonen Quellen in Stack Trace | Title |
| Stapelspur | deemphasize | Quellen in Stapelspur destieren | Conceal |
| Stapelspur | label | Stapelrahmen, die "Etiketten" sind, die keine tatsächlichen Rahmen darstellen | NonText |
| Stapelspur | subtle | Stapelrahmen, die intern oder nicht interessant sind | Conceal |
| Bereiche | arguments | Funktionsargumente Spielraum | Title |
| Bereiche | locals | Lokale Variablen Umfang | Title |
| Bereiche | registers | Register Geltungsbereich | Title |
| Variablen | property | Funktionsargumente Spielraum | Identifier |
| Variablen | method | Lokale Variablen Umfang | Function |
| Variablen | class | Register Geltungsbereich | Type |
| Variablen | data | Register Geltungsbereich | String |
Darüber hinaus kann ein in der DAP VariablePresentationHint gelieferter Wert festgelegt werden, der verwendet wird, wenn er vom Debug -Adapter geliefert wird.
Ein dummes Beispiel; Die Standardeinstellungen sollten für die meisten Farbszeheme wahrscheinlich in Ordnung sein:
let g: vimspector_presentation_hint_hl = {
' normal ' : ' Identifier ' ,
' label ' : ' Title ' ,
}Bitte beachten Sie : Diese Anpassungs -API ist instabil , was bedeutet, dass sie sich jederzeit ändern kann. Ich werde mich bemühen, die Auswirkungen davon zu verringern und Änderungen im Gitter anzukündigen.
Die folgenden Optionen steuern die Standardgrößen der UI -Fenster (alle sind Zahlen)
g:vimspector_sidebar_width (Standard: 50 Spalten): Die Breite in Spalten der linken Utility -Fenster (Variablen, Uhren, Stapelspur)g:vimspector_bottombar_height (Standard 10 Zeilen): Die Höhe in Zeilen des Ausgabefensters unterhalb des Codefensters.Beispiel:
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.
Beispiel:
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? Das ist nicht nötig. 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 " : " "
}
}
} }
