vimspector
1.0.0
Pour un didacticiel et un aperçu de l'utilisation, jetez un œil au site Web de Vimspector.
Pour une explication détaillée du format .vimspector.json , consultez le guide de référence.
Le plugin est un débogueur graphique Vim compatible avec plusieurs langues. Il est principalement testé pour C++, Python et TCL, mais prend en théorie en charge tous les langages pris en charge par Visual Studio Code (mais voir les mises en garde).
Le site Web Vimspector propose un aperçu de l'interface utilisateur, ainsi que des instructions de base pour la configuration et l'installation.
Mais pour l'instant, voici une capture d'écran (assez ancienne) de Vimspector déboguant Vim :
Et quelques brèves démos :
<Plug>VimspectorBalloonEval )Le tableau suivant répertorie les langages « intégrés » (ainsi que leurs dépendances d'exécution). Ils sont classés selon leur niveau de support :
Tested : Entièrement pris en charge, les tests de régression Vimspector les couvrentSupported : Entièrement pris en charge, fréquemment utilisé et testé manuellementExperimental : Fonctionne, mais peu utilisé et rarement testéLegacy : n'est plus pris en charge, veuillez migrer votre configurationRetired : n'est plus inclus ni pris en charge.| Langue(s) | Statut | Changer (pour install_gadget.py ) | Adaptateur (pour :VimspectorInstall ) | Dépendances |
|---|---|---|---|---|
| C, C++, Rust, Jai, etc. | Testé | --all ou --enable-c (ou cpp) | vscode-cpptools | monocœur |
| C, C++, Rust, Jai, etc. | Testé | --enable-rust , --enable-c , etc. | CodeLLDB | aucun |
| Python | Testé | --all ou --enable-python | débogage | Python3 |
| Aller | Testé | --enable-go | creuser | Allez 1.16+ |
| TCL | Soutenu | --all ou --enable-tcl | tclpro | TCL 8.5 |
| Coquille Bourne | Soutenu | --all ou --enable-bash | vscode-bash-debug | Bash v ?? |
| Lua | Testé | --all ou --enable-lua | local-lua-debugger-vscode | Nœud >=12.13.0, Npm, interpréteur Lua |
| Noeud.js | Soutenu | --force-enable-node | vscode-js-debug | Nœud >= 18 |
| Javascript | Soutenu | --force-enable-chrome | débogueur-pour-chrome | Chrome |
| Javascript | Soutenu | --force-enable-firefox | vscode-firefox-debug | Firefox |
| Java | Soutenu | --force-enable-java | vscode-java-debug | Plugin LSP compatible (voir plus loin) |
| PHP | Expérimental | --force-enable-php | vscode-php-debug | Noeud, PHP, XDEBUG |
| C# (noyau dotnet) | Testé | --force-enable-csharp | netcoredbg | Noyau DotNet |
| Fa#, VB, etc. | Soutenu | --force-enable-[fsharp,vbnet] | netcoredbg | Noyau DotNet |
| Aller (héritage) | Héritage | --enable-go | vscode-aller | Noeud, allez, fouillez |
| Python2 | Héritage | --force-enable-python2 | débogage-python2 | Python2.7 |
Vimspector devrait fonctionner pour tout adaptateur de débogage qui fonctionne dans Visual Studio Code.
Pour utiliser Vimspector avec un langage qui n'est pas "intégré", consultez cette page wiki.
Il existe 2 méthodes d'installation :
:help packages .packadd! vimspector sur votre .vimrc.vimspector.json ou définissez g:vimspector_configurations ) - consultez le guide de référenceVérifiez les dépendances
Consultez la documentation du gestionnaire de plugins et installez le plugin. Pour Vundle, utilisez :
Plugin ' puremourning/vimspector 'Installez des « gadgets » (adaptateurs de débogage) – voir ici pour les commandes d'installation et sélectionnez les gadgets à installer
Configurez les profils de débogage de votre projet (créez .vimspector.json ou définissez g:vimspector_configurations ) - consultez le guide de référence
Les sections suivantes développent le bref aperçu ci-dessus.
Vimspector nécessite :
Quelles versions de Linux ? Je teste uniquement sur Ubuntu 20.04 et versions ultérieures et RHEL 7.
neovim n'implémente pas les bulles de survol de la souris. À la place, il existe le mappage <Plug>VimspectorBalloonEval . Il n'y a pas de mappage par défaut pour cela, je recommande donc quelque chose comme ceci pour obtenir l'affichage des variables dans une fenêtre contextuelle :
" 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> VimspectorBalloonEvalLes fonctionnalités suivantes ne sont pas implémentées pour Windows :
Si vous souhaitez simplement essayer vimspector sans modifier votre configuration vim, il existe des exemples de projets pour un certain nombre de langages dans support/test , notamment :
Pour en tester un, accédez au répertoire et exécutez :
vim -Nu /path/to/vimspector/tests/vimrc --cmd "let g:vimspector_enable_mappings='HUMAN'"
Appuyez ensuite sur <F5> .
Il existe également un projet C++ dans tests/testdata/cpp/simple/ avec un Makefile qui peut être utilisé pour vérifier que tout fonctionne. Ceci est utilisé par les tests de régression dans CI et devrait donc toujours fonctionner, et constitue un bon moyen de vérifier si le problème vient de votre configuration plutôt que d'un bug.
Il existe de nombreux gestionnaires de plugins Vim, et je ne vais pas énoncer une préférence particulière, donc si vous choisissez d'en utiliser un, suivez la documentation du gestionnaire de plugins. Par exemple, pour Vundle, utilisez :
Plugin ' puremourning/vimspector 'Si vous n'utilisez pas déjà de gestionnaire de plugins, installez vimspector en tant que package Vim en clonant ce référentiel dans le chemin de votre package, comme ceci :
$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector
.vimrc , par exemple pour activer les mappages standards : let g: vimspector_enable_mappings = ' HUMAN '.vimrc après avoir configuré vimspector : packadd! vimspector
Voir support/doc/example_vimrc.vim pour un exemple minimal.
Vimspector est un client générique pour les adaptateurs de débogage. Les adaptateurs de débogage (appelés « gadgets » ou « adaptateurs ») sont ce qui fait réellement le travail de communication avec les vrais débogueurs.
Pour que Vimspector soit utile, vous devez installer des adaptateurs.
Il existe plusieurs façons de procéder :
:VimspectorInstall <adapter> <args...> (utilisez wildmenu TAB pour voir les options, accepte également toute option install_gadget.py )python3 install_gadget.py <args> (utilisez --help pour voir toutes les options):VimspectorUpdate pour installer les dernières versions prises en charge des gadgets.Voici une démo de quelques installations et d'une mise à niveau :
install_gadget.py et :VimspectorInstall font le même ensemble de choses, bien que les comportements par défaut soient légèrement différents. Pour les langues prises en charge, ils :
gadgetDir pour la plateforme.Par exemple, pour installer l'adaptateur de débogage testé pour une langue, exécutez :
| Pour installer | Scénario | Commande |
|---|---|---|
<adapter> | :VimspectorInstall <adapter> | |
<adapter1> , <adapter2> , ... | :VimspectorInstall <adapter1> <adapter2> ... | |
<language> | ./install_gadget.py --enable-<language> ... | :VimspectorInstall --enable-<language> ... |
| Adaptateurs pris en charge | ./install_gadget.py --all | :VimspectorInstall --all |
| Adaptateurs pris en charge, mais pas TCL | ./install_gadget.py --all --disable-tcl | :VimspectorInstall --all --disable-tcl |
| Adaptateurs pris en charge et expérimentaux | ./install_gadget.py --all --force-all | :VimspectorInstall --all |
| Adaptateur pour une configuration de débogage spécifique | Suggéré par Vimspector au démarrage du débogage |
:VimspectorInstall exécute install_gadget.py en arrière-plan avec certaines options par défaut.
:VimspectorUpdate exécute install_gadget.py pour réinstaller (c'est-à-dire mettre à jour) tous les gadgets déjà installés dans votre .gadgets.json .
La sortie est minime, pour voir la sortie complète, ajoutez --verbose à la commande, comme dans :VimspectorInstall --verbose ... ou :VimspectorUpdate --verbose ... .
Si l'installation réussit, la fenêtre de sortie est fermée (et la sortie est perdue à jamais). Utilisez un ! pour le garder ouvert (par exemple :VimspectorInstall! --verbose --all ou :VimspectorUpdate! (etc.).
Si vous savez à l'avance quels gadgets vous souhaitez installer, par exemple pour pouvoir reproduire votre configuration à partir du contrôle de code source, vous pouvez définir g:vimspector_install_gadgets sur une liste de gadgets. Celui-ci sera utilisé lorsque :
:VimspectorInstall sans argument, ou:VimspectorUpdatePar exemple:
let g: vimspector_install_gadgets = [ ' debugpy ' , ' vscode-cpptools ' , ' CodeLLDB ' ] Par défaut, install_gadget.py écrasera votre .gadgets.json avec l'ensemble d'adaptateurs qui vient d'être installé, tandis que :VimspectorInstall le mettra à jour , en écrasant uniquement les adaptateurs nouvellement modifiés ou installés.
Si vous souhaitez simplement ajouter un nouvel adaptateur à l'aide du script sans détruire ceux existants, ajoutez --update-gadget-config , comme dans :
$ ./install_gadget.py --enable-tcl
$ ./install_gadget.py --enable-rust --update-gadget-config
$ ./install_gadget.py --enable-java --update-gadget-config Si vous souhaitez conserver configurations en dehors du référentiel vimspector (cela peut être utile si vous avez des gadgets personnalisés ou des configurations globales), vous pouvez demander au programme d'installation d'utiliser un répertoire de base différent, puis définir g:vimspector_base_dir pour qu'il pointe vers ce répertoire, par exemple. :
$ ./install_gadget.py --basedir $HOME /.vim/vimspector-config --all --force-all Ajoutez ensuite ceci à votre .vimrc :
let g: vimspector_base_dir = expand ( ' $HOME/.vim/vimspector-config ' ) Lors de l'utilisation :VimspectorInstall , le paramètre g:vimspector_base_dir est respecté sauf si --basedir est ajouté manuellement (non recommandé).
Voir --help pour plus d'informations sur les différentes options.
Si la langue que vous souhaitez déboguer ne figure pas dans la liste prise en charge ci-dessus, vous pouvez probablement toujours la faire fonctionner, mais cela demande plus d'efforts.
Vous devez essentiellement obtenir une installation fonctionnelle de l'adaptateur de débogage, découvrir comment le démarrer et le configurer dans une entrée adapters dans votre .vimspector.json ou dans .gadgets.json ou dans g:vimspector_adapters .
Le moyen le plus simple en pratique est d'installer ou de démarrer Visual Studio Code et d'utiliser son gestionnaire d'extensions pour installer l'extension concernée. Vous pouvez ensuite configurer l'adaptateur manuellement dans la section adapters de votre .vimspector.json ou dans un gadgets.json ou dans g:vimspector_adapters .
Les PR sont toujours invités à ajouter des langues prises en charge (ce qui se traduit en gros par la mise à jour python/vimspector/gadgets.py et par son test).
Vimspector utilise le répertoire suivant par défaut pour rechercher un fichier nommé .gadgets.json : </path/to/vimspector>/gadgets/<os> .
Ce chemin est exposé en tant que variable vimspector ${gadgetDir} . Ceci est utile pour configurer les lignes de commande du gadget.
Où os est l'un des éléments suivants :
macoslinuxwindows (attention cependant : Windows n'est pas pris en charge) Le format est le même que .vimspector.json , mais seule la clé adapters est utilisée :
Exemple:
{
"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 "
}
}
} Le fichier gadget est automatiquement écrit par install_gadget.py (ou :VimspectorInstall ).
Vimspector chargera également tous les fichiers correspondant à : </path/to/vimspector>/gadgets/<os>/.gadgets.d/*.json . Ceux-ci ont le même format que .gadgets.json mais ne sont pas écrasés lors de l'exécution install_gadget.py .
Après avoir mis à jour le code de Vimspector (via git pull ou n'importe quel gestionnaire de packages), exécutez :VimspectorUpdate pour mettre à jour tous les gadgets déjà installés.
La motivation est que le débogage dans Vim est une expérience assez horrible, surtout si vous utilisez plusieurs langues. Avec pyclewn terminé et le plugin termdebug intégré limité à gdb, je voulais explorer les options.
Alors que le protocole Language Server est bien connu, le protocole Debug Adapter est moins connu, mais atteint un objectif similaire : une API indépendante du langage extrayant les débogueurs des clients.
L'objectif de ce projet est de fournir une expérience de débogage simple mais efficace dans Vim pour plusieurs langages, en tirant parti des adaptateurs de débogage en cours de construction pour Visual Studio Code.
La possibilité d'effectuer du débogage à distance est indispensable. C'est la clé de mon flux de travail, donc l'intégrer à l'expérience de débogage est un objectif majeur du projet. Ainsi, vimspector dispose d'un support de premier ordre pour exécuter des programmes à distance et s'y attacher. Cette prise en charge est unique à vimspector et s'ajoute (en complément) à toute prise en charge de ce type dans les adaptateurs de débogage réels.
Vimspector est une interface utilisateur vim au-dessus du protocole d'adaptateur de débogage. Il est destiné à être de haut niveau et pratique pour les tâches de débogage quotidiennes.
Vimspector n'est pas :
Vimspector est un travail en cours, et tous les commentaires/contributions sont plus que bienvenus.
Le backlog peut être consulté sur Trello.
Le plugin est actuellement expérimental . Cela signifie que n’importe quelle partie peut (et va probablement) changer, y compris des éléments tels que :
Cependant, je m'engage à ne le faire que dans les cas les plus extrêmes et à annoncer ces changements sur Gitter longtemps à l'avance. Il n'y a rien de plus énervant que des choses qui vous tombent dessus. Je comprends ça.
Un message de l'auteur sur la motivation de ce plugin :
De nombreux environnements de développement disposent d'un débogueur intégré. Je passe énormément de temps dans Vim. Je fais tout mon développement dans Vim et j'ai même personnalisé mes flux de travail pour créer du code, exécuter des tests, etc.
Depuis de nombreuses années, j'observe moi-même, mes amis et mes collègues écrivent des instructions de débogage
printf,puts,Je crois sincèrement que les environnements de débogage graphiques et interactifs sont le meilleur moyen de comprendre et de raisonner à la fois sur du code inconnu et familier, et que le manque d'accès simple et prêt à un débogueur est un énorme trou de productivité caché pour beaucoup.
Ne vous méprenez pas, je sais qu'il y a littéralement des millions de développeurs qui sont plus que compétents pour développer sans débogueur graphique, mais je maintiens que s'ils avaient la possibilité d' appuyer simplement sur une touche et de passer au débogueur, cela serait plus rapide et plus agréable que la simple compréhension cérébrale du code.
J'ai créé Vimspector parce que je trouve frustrant de changer d'outil.
gdbpour c++,pdbpour python, etc. Chacun a sa propre syntaxe. A chacun son lexique. Chacun ses points faibles.J'ai conçu le système de configuration de telle manière que la configuration puisse être validée dans le contrôle de source afin qu'elle fonctionne uniquement pour n'importe lequel de vos collègues, amis, collaborateurs ou parfaits inconnus.
J'ai fait du débogage à distance une fonctionnalité de premier ordre car c'est un cas d'utilisation principal pour moi dans mon travail.
Avec Vimspector, je peux simplement appuyer sur
<F5>dans tous les langages dans lesquels je développe et déboguer localement ou à distance en utilisant exactement le même flux de travail, les mêmes mappages et la même interface utilisateur. Je l'ai intégré à mon Vim de telle manière que je puisse appuyer sur un bouton et exécuter le test sous le curseur dans Vimspector . Ce type d'intégration a considérablement amélioré mon flux de travail et ma productivité. Cela a même rendu le processus d'apprentissage d'une nouvelle base de code... amusant.- Ben Jackson, créateur.
Apache2.0
Copyright © 2018 Ben Jackson
Si vous aimez tellement Vimspector que vous êtes prêt à vous séparer de votre argent durement gagné, pensez à faire un don à l'un des organismes de bienfaisance suivants, qui sont importants pour l'auteur de Vimspector (par ordre de préférence) :
Par défaut, vimspector ne modifie aucun de vos mappages. Les mappages sont très personnels et vous devez donc déterminer ce que vous aimez et utiliser les puissantes fonctionnalités de mappage de vim pour définir vos propres mappages. À cette fin, Vimspector définit les mappages <Plug> suivants :
| Cartographie | Fonction | API |
|---|---|---|
<Plug>VimspectorContinue | Lors du débogage, continuez. Sinon, lancez le débogage. | vimspector#Continue() |
<Plug>VimspectorStop | Arrêtez le débogage. | vimspector#Stop() |
<Plug>VimpectorRestart | Redémarrez le débogage avec la même configuration. | vimspector#Restart() |
<Plug>VimspectorPause | Suspendre le débogueur. | vimspector#Pause() |
<Plug>VimspectorBreakpoints | Afficher/masquer la fenêtre des points d'arrêt | vimspector#ListBreakpoints() |
<Plug>VimspectorToggleBreakpoint | Bascule le point d'arrêt de ligne sur la ligne actuelle. | vimspector#ToggleBreakpoint() |
<Plug>VimspectorToggleConditionalBreakpoint | Basculer le point d'arrêt de ligne conditionnel ou le point de journalisation sur la ligne actuelle. | vimspector#ToggleBreakpoint( { trigger expr, hit count expr } ) |
<Plug>VimspectorAddFunctionBreakpoint | Ajouter un point d'arrêt de fonction pour l'expression sous le curseur | vimspector#AddFunctionBreakpoint( '<cexpr>' ) |
<Plug>VimspectorGoToCurrentLine | Remettre le compteur du programme en cours à la ligne en cours | vimspector#GoToCurrentLine() |
<Plug>VimspectorRunToCursor | Courir vers le curseur | vimspector#RunToCursor() |
<Plug>VimspectorStepOver | Enjamber | vimspector#StepOver() |
<Plug>VimspectorStepInto | Entrez dans | vimspector#StepInto() |
<Plug>VimspectorStepOut | Sortir du champ de fonction actuel | vimspector#StepOut() |
<Plug>VimspectorDisassemble | Montrer le démontage. Activer le pas à pas des instructions | vimspector#ShowDisassembly() |
<Plug>VimspectorUpFrame | Remonter d'un cadre dans la pile d'appels actuelle | vimspector#UpFrame() |
<Plug>VimspectorDownFrame | Descendre d'un cadre dans la pile d'appels actuelle | vimspector#DownFrame() |
<Plug>VimspectorJumpToNextBreakpoint | Déplacer le curseur vers le point d'arrêt suivant dans le fichier actuel | vimspector#JumpToNextBreakpoint() |
<Plug>VimspectorJumpToPreviousBreakpoint | Déplacer le curseur vers le point d'arrêt précédent dans le fichier actuel | vimspector#JumpToPreviousBreakpoint() |
<Plug>VimspectorJumpToProgramCounter | Déplacer le curseur vers le compteur de programme dans l'image actuelle | vimspector#JumpToProgramCounter() |
<Plug>VimspectorBalloonEval | Évaluer l'expression sous le curseur (ou visuel) dans une fenêtre contextuelle | interne |
Ceux-ci correspondent à peu près 1-1 avec les fonctions API ci-dessous.
Par exemple, si vous souhaitez que <F5> démarre/continue le débogage, ajoutez-le à un endroit approprié, tel que votre vimrc (indice : exécutez :e $MYVIMRC ).
nmap <F5> <Plug> VimspectorContinueDe plus, de nombreux utilisateurs souhaitent probablement activer uniquement certains mappages Vimspector lorsque le débogage est actif. Ceci est également possible, même si cela nécessite d'écrire un vimscipt.
Cela dit, de nombreuses personnes connaissent des débogueurs particuliers, les mappages suivants peuvent donc être activés en définissant g:vimspector_enable_mappings sur la valeur spécifiée.
Pour utiliser des mappages de type Visual Studio, ajoutez ce qui suit à votre vimrc avant de charger vimspector :
let g: vimspector_enable_mappings = ' VISUAL_STUDIO '| Clé | Cartographie | Fonction |
|---|---|---|
F5 | <Plug>VimspectorContinue | Lors du débogage, continuez. Sinon, lancez le débogage. |
Shift F5 | <Plug>VimspectorStop | Arrêtez le débogage. |
Ctrl Shift F5 | <Plug>VimspectorRestart | Redémarrez le débogage avec la même configuration. |
F6 | <Plug>VimspectorPause | Suspendre le débogueur. |
F8 | <Plug>VimspectorJumpToNextBreakpoint | Passer au point d'arrêt suivant dans le fichier actuel. |
Shift F8 | <Plug>VimspectorJumpToPreviousBreakpoint | Passer au point d'arrêt précédent dans le fichier actuel. |
F9 | <Plug>VimspectorToggleBreakpoint | Bascule le point d'arrêt de ligne sur la ligne actuelle. |
Shift F9 | <Plug>VimspectorAddFunctionBreakpoint | Ajouter un point d'arrêt de fonction pour l'expression sous le curseur |
F10 | <Plug>VimspectorStepOver | Enjamber |
Ctrl F10 | <Plug>VimspectorRunToCursor | Courir jusqu'au curseur* |
F11 | <Plug>VimspectorStepInto | Entrez dans |
Shift F11 | <Plug>VimspectorStepOut | Sortir du champ de fonction actuel |
Alt 8 | <Plug>VimspectorDisassemble | Afficher le démontage |
REMARQUE : Certains mappages, tels que les touches ctrl et F, peuvent ne pas fonctionner en fonction de votre terminal, de votre clavier, de votre système de fenêtrage et de toutes sortes d'autres choses. Voir :help modifyOtherKeys et d'autres sources. Si vous ne parvenez pas à faire fonctionner cela, utilisez simplement les mappages « mode humain ».
Si, comme moi, vous n'avez que 2 mains et 10 doigts, vous n'aimez probablement pas les touches Ctrl-Shift-F. De plus, si vous utilisez un terminal, il existe une réelle possibilité que terminfo soit erroné pour les touches F décalées, en particulier si votre TERM est screen-256color . Si ces problèmes (nombre de mains, variables TERM ) ne sont pas résolus, essayez les mappages suivants, en ajoutant ce qui suit avant de charger vimspector :
let g: vimspector_enable_mappings = ' HUMAN '| Clé | Cartographie | Fonction |
|---|---|---|
F5 | <Plug>VimspectorContinue | Lors du débogage, continuez. Sinon, lancez le débogage. |
F3 | <Plug>VimspectorStop | Arrêtez le débogage. |
F4 | <Plug>VimspectorRestart | Redémarrez le débogage avec la même configuration. |
F6 | <Plug>VimspectorPause | Suspendre le débogueur. |
F9 | <Plug>VimspectorToggleBreakpoint | Bascule le point d'arrêt de ligne sur la ligne actuelle. |
<leader>F9 | <Plug>VimspectorToggleConditionalBreakpoint | Basculer le point d'arrêt de ligne conditionnel ou le point de journalisation sur la ligne actuelle. |
F8 | <Plug>VimspectorAddFunctionBreakpoint | Ajouter un point d'arrêt de fonction pour l'expression sous le curseur |
<leader>F8 | <Plug>VimspectorRunToCursor | Courir vers le curseur |
F10 | <Plug>VimspectorStepOver | Enjamber |
F11 | <Plug>VimspectorStepInto | Entrez dans |
F12 | <Plug>VimspectorStepOut | Sortir du champ de fonction actuel |
De plus, je recommande d'ajouter un mappage à <Plug>VimspectorBalloonEval , en modes normal et visuel, par exemple :
" 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> VimspectorBalloonEvalVous souhaiterez peut-être également ajouter des mappages pour naviguer vers le haut/bas dans la pile, basculer la fenêtre des points d'arrêt et afficher le démontage, par exemple :
nmap <LocalLeader> <F11> <Plug> VimspectorUpFrame
nmap <LocalLeader> <F12> <Plug> VimspectorDownFrame
nmap <LocalLeader> B <Plug> VimspectorBreakpoints
nmap <LocalLeader> D <Plug> VimspectorDisassembleCette section définit des instructions d'utilisation détaillées, organisées par fonctionnalité. Pour la plupart des utilisateurs, la section mappages contient les commandes les plus courantes et leur utilisation par défaut. Cette section peut être utilisée comme référence pour créer vos propres mappages ou comportements personnalisés.
Toutes les instructions ci-dessous supposent une seule session de débogage. Pour plus de détails sur la façon de déboguer plusieurs applications indépendantes en même temps, consultez [plusieurs sessions de débogage] [#multiple-debugging-sessions].
.vimspector.json . Voir ci-dessous.:call vimspector#Launch() et sélectionnez une configuration.Le lancement d'une nouvelle session en fait la [session de débogage][#multiple-debugging-sessions] active.
Si la configuration de l'adaptateur de débogage utilise pidProperty et que vous effectuez une demande attach , il vous sera alors demandé de saisir un PID (ID de processus) auquel vous connecter.
Pour rendre cela plus facile, Vimspector fournit un petit utilitaire permettant de lister les PID. C'est comme un clone très très simple de ps mais fonctionne sur toutes les plateformes supportées. Consultez son README pour obtenir des instructions sur sa configuration.
Exécutez go build dans le répertoire support/vimspector_process_list pour le configurer.
Si Vimspector parvient à trouver cette application, il tentera par défaut de répertorier tous les processus appartenant à l'utilisateur actuel.
Alternativement (de préférence), vous pouvez utiliser une forme spéciale d'expansion de variable appelée ${PickProcess("binaryName")} . La version de cet appel listera tous les processus de l'utilisateur actuel qui correspondent à ce nom binaire.
Par exemple:
"Attach" : {
"adapter" : "CodeLLDB" ,
"configuration" : {
"request" : "attach" ,
"program" : "${workspaceRoot}/Jails" ,
"pid" : "${PickProcess("jails")}"
}
}Cela listera chaque processus correspondant, son processus parent, son heure de début et son répertoire de travail. Cela ressemble à ceci :
PID PPID CWD START
52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24
Enter Process ID:
Vous entrez ensuite le PID et appuyez sur <CR> .
Vous pouvez même remplacer le sélecteur de processus par votre propre fonction. Si vous définissez une fonction et définissez g:vimspector_custom_process_picker_func sur le nom de cette fonction. Tous les arguments transmis à la fonction d'expansion PickProcess lui seront transmis. Il sera également utilisé chaque fois qu'un pidProperty est spécifié, il ne doit donc également gérer aucun argument (utilisez ... comme arguments formels pour la fonction, voir :help ... ).
Par exemple, pour utiliser fzf avec le vimspector_process_list fourni :
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 ' Ou d'utiliser fzf avec la sortie de ps :
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 'Pour lancer une configuration de débogage spécifique, ou spécifier des variables de remplacement pour le lancement, vous pouvez utiliser :
:call vimspector#LaunchWithSettings( dict ) L'argument est un dict avec les clés suivantes :
configuration : (facultatif) Nom de la configuration de débogage à lancer<anything else> : (facultatif) Nom d'une variable à définir Cela permet une certaine intégration et automatisation. Par exemple, si vous disposez d'une configuration nommée Run Test qui contient une variable de remplacement nommée ${Test} vous pouvez écrire un mappage qui s'exécute finalement :
vimspector#LaunchWithSettings ( #{ configuration: ' Run Test '
Test: ' Name of the test ' } ) Cela démarrerait la configuration Run Test avec ${Test} défini sur 'Name of the test' et Vimspector n'inviterait pas l'utilisateur à saisir ou à confirmer ces éléments.
Consultez notre guide d'intégration YouCompleteMe pour un autre exemple où il peut être utilisé pour spécifier le port pour connecter le débogueur Java.
Pour lancer avec une configuration ad hoc, vous pouvez utiliser :
call vimspector#LaunchWithConfigurations( dict ) L'argument est un dict qui est la section configurations d'un fichier .vimspector. Transmettez une configuration et celle-ci sera sélectionnée comme celle à exécuter. Par exemple:
let pid = <some_expression>
call vimspector#LaunchWithConfigurations ({
" attach " : {
" adapter " : " netcoredbg " ,
" configuration " : {
" request " : " attach " ,
" processId " : pid
}
}
} ) Cela lancerait le débogueur et s'attacherait au processus spécifié sans qu'il soit nécessaire d'avoir un fichier .vimspector local sur le disque. La variable ${workspaceRoot} pointera vers le dossier parent du fichier actuellement ouvert dans vim.
Vimspector utilise la logique suivante pour choisir une configuration à lancer :
autoselect définie sur false , utilisez-la.default défini sur true et sans autoselect défini sur false , utilisez-la.Consultez le guide de référence pour plus de détails.
vimspector#GetConfigurations() pour obtenir une liste de configurations pour le type de fichier du tampon actuelPar exemple, pour obtenir un tableau de configurations et une correspondance floue sur le résultat
: call matchfuzzy ( vimspector#GetConfigurations (), " test::case_1 " )Consultez la section mappages pour connaître les mappages par défaut permettant de travailler avec des points d'arrêt. Cette section décrit l'API complète dans les fonctions vimscript.
Les points d'arrêt sont associés à la [session de débogage][#multiple-debugging-sessions] en cours. Lors du basculement entre les sessions, les signes de pont d'arrêt de la session précédente sont supprimés et les points d'arrêt de la session nouvellement activée sont affichés. Même s'il peut être utile d'afficher les points d'arrêt pour toutes les sessions, cela peut être très déroutant.
Utilisez :VimspectorBreakpoints ou mappez quelque chose à <Plug>VimspectorBreakpoints pour ouvrir la vue des points d'arrêt. À partir de là, vous pouvez lister, sauter pour supprimer, ajouter et basculer des points d'arrêt.
Je recommande un mappage comme celui-ci pour basculer la fenêtre des points d'arrêt :
nmap <Leader> db <Plug> VimspectorBreakpointsLes mappages suivants s'appliquent par défaut dans la fenêtre des points d'arrêt :
t , <F9> - bascule, c'est-à-dire activer/désactiver le point d'arrêtT - bascule, c'est-à-dire activer/désactiver TOUS les points d'arrêtdd , <Del> - supprime le point d'arrêt actuelcc , C - modifier les options du point d'arrêt actueli , a , o - ajoute un nouveau point d'arrêt de ligneI , A , O - ajoute un nouveau point d'arrêt de fonction<Enter> ou double-clic - saute au point d'arrêt de ligneUn WinBar est également fourni (si pris en charge). Cela ajoute des fonctions telles que l'enregistrement/la restauration de sessions, la suppression de tous les points d'arrêt et la réinitialisation des options de points d'arrêt d'exception.
La forme de point d’arrêt la plus simple et la plus courante est un point d’arrêt de ligne. L'exécution est suspendue lorsque la ligne spécifiée est exécutée.
Pour la plupart des scénarios de débogage, les utilisateurs appuient simplement sur <F9> pour créer un point d'arrêt de ligne sur la ligne actuelle et sur <F5> pour lancer l'application.
Certains adaptateurs de débogage prennent en charge les points d'arrêt conditionnels. Notez que vimspector ne vous indique pas si le débogueur ne prend pas (encore) en charge les points d'arrêt conditionnels. Un point d'arrêt conditionnel est un point d'arrêt qui se déclenche uniquement si une expression est évaluée comme vraie ou si d'autres contraintes sont respectées.
Certaines de ces fonctions ci-dessus prennent un seul argument facultatif qui est un dictionnaire d'options. Le dictionnaire peut avoir les clés suivantes :
condition : Une expression facultative évaluée pour déterminer si le point d’arrêt doit se déclencher. Non pris en charge par tous les adaptateurs de débogage. Par exemple, pour arrêter lorsque abc vaut 10 , entrez quelque chose comme abc == 10 , selon la langue.hitCondition : une expression facultative évaluée pour déterminer le nombre de fois où le point d'arrêt doit être ignoré. Ne devrait (probablement ?) pas être utilisé en combinaison avec condition . Non pris en charge par tous les adaptateurs de débogage. Par exemple, pour interrompre la troisième fois en frappant cette ligne, saisissez 3 .logMessage : une chaîne facultative pour faire de ce point d'arrêt un "point de journalisation" à la place. Lorsqu'il est déclenché, ce message est imprimé sur la console plutôt que d'interrompre l'exécution. Vous pouvez intégrer des expressions entre accolades {like this} , par exemple #{ logMessage: "Iteration {i} or {num_entries / 2}" }Dans chaque cas, les expressions sont évaluées par le débogueur et doivent donc être utilisées dans le dialecte que le débogueur comprend lors de l'évaluation des expressions.
Lors de l'utilisation du mappage <leader><F9> , l'utilisateur est invité à saisir ces expressions dans une ligne de commande (avec historique).
Les points d'arrêt d'exception se déclenchent généralement lorsqu'une exception est levée ou qu'une autre condition d'erreur se produit. Selon le débogueur, lors du démarrage du débogage, quelques questions peuvent vous être posées sur la façon de gérer les exceptions. Ce sont des "points d'arrêt d'exception" et vimspector se souvient de vos choix pendant que Vim est toujours en cours d'exécution.
En règle générale, vous pouvez accepter les valeurs par défaut (continuez simplement à appuyer sur <CR> !) car la plupart des valeurs par défaut de l'adaptateur de débogage sont saines, mais si vous souhaitez continuer, dites uncaught exception , puis répondez Y à cela (par exemple).
Vous pouvez configurer vos choix dans le .vimspector.json . Consultez le guide de configuration pour plus de détails à ce sujet.
REMARQUE : auparavant, ToggleBreakpoint alternait entre 3 états : activé, désactivé, supprimé. De nombreux utilisateurs ont trouvé que l'état « désactivé » était rarement utile, c'est pourquoi le comportement a été modifié. ToggleBreakpoint crée ou supprime toujours un point d'arrêt. Si vous souhaitez "désactiver" les points d'arrêt, utilisez la fenêtre des points d'arrêt et "basculez" ( t ) à partir de là.
vimspector#ToggleBreakpoint( { options dict } ) pour définir/supprimer un point d'arrêt de ligne. L'argument est facultatif (voir ci-dessous).vimspector#AddFunctionBreakpoint( '<name>', { options dict} ) pour ajouter un point d'arrêt de fonction. Le deuxième argument est facultatif (voir ci-dessous).vimspector#SetLineBreakpoint( file_name, line_num, { options dict } ) pour définir un point d'arrêt sur un fichier/une ligne spécifique. Le dernier argument est facultatif (voir ci-dessous)vimspector#ClearLineBreakpoint( file_name, line_num ) pour supprimer un point d'arrêt sur un fichier/une ligne spécifiquevimspector#ClearBreakpoints() pour effacer tous les points d'arrêtvimspector#ResetExceptionBreakpoints() pour effacer la configuration des points d'arrêt d'exception et répondre à nouveau aux différentes questions telles que "Break on C++ Throw":VimspectorMkSession et :VimspectorLoadSession pour enregistrer et restaurer les points d'arrêtcall vimspector#ListBreakpoints() - basculer la fenêtre des points d'arrêtcall vimspector#BreakpointsAsQuickFix() - renvoie l'ensemble actuel de points d'arrêt au format vim quickfixExemples :
call vimspector#ToggleBreakpoint() - bascule le point d'arrêt sur la ligne actuellecall vimspector#SetLineBreakpoint( 'some_file.py', 10 ) - définit un point d'arrêt sur some_filepy:10call vimspector#AddFunctionBreakpoint( 'main' ) - ajoute un point d'arrêt de fonction sur la fonction maincall vimspector#ToggleBreakpoint( { 'condition': 'i > 5' } ) - ajoute un point d'arrêt sur la ligne actuelle qui se déclenche uniquement lorsque i > 5 est truecall vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i > 5' } ) - ajoute un point d'arrêt à some_file.py:10 qui se déclenche uniquement lorsque i > 5 est truecall vimspector#ClearLineBreakpoint( 'some_file.py', 10 ) - supprimez le point d'arrêt à some_file.py:10call vimspector#ClearBreakpoints() - efface tous les points d'arrêtVimspectorMkSession - créer .vimspector.sessionVimspectorLoadSession - lire .vimspector.sessionVimspectorMkSession my_session_file - créer my_session_fileVimspectorLoadSession my_session_file - lire my_session_fileREMARQUE : fonctionnalité expérimentale, qui pourrait changer considérablement à l'avenir en fonction des commentaires des utilisateurs.
Les points d'arrêt d'instruction peuvent être ajoutés à partir de la fenêtre de désassemblage de la même manière que vous ajoutez des points d'arrêt de ligne dans la fenêtre de code. Les mêmes mappages et fonctions fonctionnent pour les ajouter et les basculer. Lorsque cela est pris en charge par l'adaptateur de débogage, vous pouvez même créer des points de journalisation et des points d'arrêt conditionnels de cette manière.
Actuellement, les points de rupture des instructions sont modélisés en interne sous forme de points d'arrêt de ligne contre le tampon contenant le démontage, mais cela peut changer à l'avenir, alors ne comptez pas sur cela.
Les points d'arrêt de l'instruction sont également visibles et peuvent être supprimés / désactivés de la fenêtre des points d'arrêt.
Actuellement, les points de rupture des instructions sont automatiquement effacés à la fin de la session de débogage. La raison en est que les adresses ne peuvent être garanties pour être valides pour toute autre session de débogage. Cependant, cela pourrait également changer à l'avenir.
Utilisez vimspector#ClearBreakpoints() pour effacer tous les points d'arrêt, y compris la mémoire des choix de points d'arrêt des exceptions.
Utilisez vimspector#RunToCursor ou <leader><F8> : Cela crée un point d'arrêt temporaire sur la ligne actuelle, puis continue l'exécution, effaçant le point d'arrêt lorsqu'il est touché.
Utilisez vimspector#GoToCurrentLine() ou un mappage pour <Plug>VimspectorGoToCurrentLine pour sauter l'exécution actuelle sur la ligne sur laquelle votre curseur est actuellement.
Lorsque cela est pris en charge, cela peut être utile pour réintégrer les sections de code ou les sauter entièrement.
S'il y a plusieurs "cibles" possibles sur la ligne actuelle, vous êtes invité à en choisir un.
VIMSpector peut enregistrer et restaurer des points d'arrêt (et d'autres choses) dans un fichier de session. Les commandes suivantes existent pour cela:
VimspectorMkSession [file/dir name] - Enregistrez l'ensemble actuel des points d'arrêt de ligne, des points de log, des points d'arrêt conditionnels, des points d'arrêt des fonctions et des filtres de point d'arrêt des exceptions dans le fichier de session fourni ou le fichier par défaut dans le répertoire fourni.VimspectorLoadSession [file/dir name] - Lisez les points d'arrêt du fichier de session fourni ou du fichier par défaut dans le répertoire fourni et remplacez tous les points d'arrêt actuellement. Avant le chargement, tous les points d'arrêt actuels sont effacés (comme si vimspector#ClearLineBreakpoints() était appelé). Dans les deux cas, l'argument de nom de fichier / dir est facultatif. Par défaut, le fichier est nommé .vimspector.session , mais cela peut être modifié globalement en définissant g:vimspector_session_file_name à quelque chose d'autre, ou en spécifiant manuellement un chemin lors de l'appel de la commande. Si vous fournissez un répertoire, le nom de fichier de session par défaut ou configuré est lu par Fron ou écrit dans ce répertoire. Otewise, le fichier est lu en fonction du tampon actuellement ouvert ou écrit dans le répertoire de travail actuel.
Les utilisateurs avancés peuvent souhaiter automatiser le processus de chargement et de sauvegarde, par exemple en ajoutant des autocommands VimEnter et VimLeave . Il est recommandé dans ce cas d'utiliser silent! Pour éviter les erreurs ennuyeuses si le fichier ne peut pas être lu ou écrit.
La forme la plus simple d'automatisation est de charger la session VIMSpector chaque fois que vous démarrez VIM avec un fichier de session. C'est aussi simple que de faire ceci:
$ echo silent VimspectorLoadSession > Sessionx.vim
Voir :help mksession pour plus de détails sur le fichier *x.vim . Vous pouvez également faire quelque chose comme celui-ci en utilisant SessionLoadPost :
autocmd SessionLoadPost * silent ! VimspectorLoadSessionvimspector#StepInto() etc. Il existe également respectivement vimspector#StepSOver() et vimspector#StepIOver() etc. <CR> , ou double-cliquez avec la souris gauche pour se développer / s'effondrer (+, -).<C-CR> (contrôle + <CR> ) ou <leader><CR> (si modifyOtherKeys ne fonctionne pas pour vous) Les portées et les variables sont représentées par le tampon vimspector.Variables .
Si vous préférez un affichage plus verbeux pour les variables et les montres, vous pouvez let g:vimspector_variables_display_mode = 'full' . Par défaut, seul le nom et la valeur s'affichent, avec d'autres données disponibles en survolant la souris ou en déclenchant <Plug>VimspectorBalloonEval sur la ligne contenant la valeur dans la fenêtre variables (ou montres).
Toutes les règles pour Variables and scopes s'appliquent plus les éléments suivants:
a + b ) et obtenez son résultat.nmap ) et en mode visuel ( xmap ) vers <Plug>VimspectorBalloonEval pour déclencher manuellement la fenêtre contextuelle.<C-CR> (contrôle + <CR> ) ou <leader><CR> (si modifyOtherKeys ne fonctionne pas pour vous)j , k ) pour choisir la sélection actuelle; <Esc> (ou laissez la fenêtre Info-toolp) pour fermer l'info-bulle. Vous pouvez désactiver la popup de planage automatique par les paramètres g:vimspector_enable_auto_hover=0 avant de démarrer la session de débogage. Vous pouvez ensuite cartographier quelque chose pour <Plug>VimspectorBalloonEval et le déclencher manuellement.
La fenêtre de montre est utilisée pour inspecter les variables et les expressions. Les expressions sont évaluées dans le cadre de pile sélectionné qui est "focalisé"
La fenêtre des montres est un tampon rapide, où cela est disponible. Entrez le mode INSERT pour ajouter une nouvelle expression de montre.
<CR> .:VimspectorWatch <expression> . La complétion d'onglet pour l'expression est disponible dans certains adaptateurs de débogage.<CR> , ou double-cliquez avec la souris gauche.<C-CR> (contrôle + <CR> ) ou <leader><CR> (si modifyOtherKeys ne fonctionne pas pour vous)<DEL> . Les montres sont représentées par le tampon vimspector.Watches .
Si vous préférez un affichage plus verbeux pour les variables et les montres, vous pouvez let g:vimspector_variables_display_mode = 'full' . Par défaut, seul le nom et la valeur s'affichent, avec d'autres données disponibles en survolant la souris ou en déclenchant <Plug>VimspectorBalloonEval sur la ligne contenant la valeur dans la fenêtre Variables (ou montres).
Vous pouvez désactiver la popup de planage automatique par les paramètres g:vimspector_enable_auto_hover=0 avant de démarrer la session de débogage. Vous pouvez ensuite cartographier quelque chose pour <Plug>VimspectorBalloonEval et le déclencher manuellement.
Le tampon d'invite de montre a son omnifunc défini sur une fonction qui calculera l'achèvement de l'expression actuelle. Ceci est trivialement utilisé avec <Ctrl-x><Ctrl-o> (voir :help ins-completion ), ou intégré à votre système d'achèvement préféré. Le type de fichier dans le tampon est défini sur VimspectorPrompt .
Pour YouCompleteMe, la configuration suivante fonctionne bien:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}:VimspectorDisassemble , vimspector#ShowDisassembly() ou <Plug>VimspectorDisassembleCertains adaptateurs de débogage (peu!) Soutiennent le démontage. La façon dont cela fonctionne dans DAP est un peu bizarre, mais en pratique, VimSpector demandera à démonter un certain nombre d'instructions autour du PC actuel du cadre de pile. Ceci est ensuite illustré dans une fenêtre avec un Winbar similaire à la fenêtre de code, mais avec l'instruction en passant par la granularité. Il y a un panneau pour l'instruction actuelle et la syntaxe Highighting par défaut est "ASM" qui fonctionne principalement OK pour x86 et ARM.
Comme mentionné ci-dessus, lorsque votre fenêtre actuelle est les fenêtres de désassemblage et que vous utilisez les commandes "Step" par défaut (par exemple <F10> ), le trempage est automatiquement réduit par l'instruction plutôt que par instruction.
Chaque fois que le processus s'arrête, VimSpector demande environ 2 fenêtres pleines d'instructions autour du PC actuel. Pour en voir plus, vous pouvez faire défiler la fenêtre. VIMSPECTOR PAGERA DANS UNE ÉCRAN ENTRE ÉCRANSE D'INSTRUCTIONS lorsque la fenêtre défile en haut ou près du bas. Ce n'est pas parfait. Parfois, vous devez faire défiler un peu plus pour le faire dans la page (par exemple, Ctrl-E Ctrl-y en haut). Ce n'est pas idéal et peut être amélioré à l'avenir.
Vous pouvez contrôler la hauteur intime de la fenêtre de démontage avec let g:vimspector_disassembly_height = 10 (ou Whatver Nombre de lignes).
Le type de fichier (et la syntaxe) des tampons dans la fenêtre de démontage est vimspector-disassembly . Vous pouvez utiliser FileType AutoCommands pour personnaliser des choses comme la mise en évidence de la syntaxe.
Remarque : Cette fonctionnalité est expérimentale et peut changer de quelque manière que ce soit en fonction des commentaires des utilisateurs.
Certains adaptateurs de débogage fournissent un moyen de vider la mémoire de processus associée aux variables. Cela peut être fait à partir des variables et regarde les fenêtres avec:
<leader>m (par défaut, peut être personnalisé)vimspector#ReadMemory() Fonction Ce faisant, il vous est demandé de saisir un certain nombre d'octets à lire (à partir de l'emplacement associé à la ligne de curseur actuelle) et un décalage de cet emplacement. Un nouveau tampon s'affiche dans la fenêtre de code contenant un vidage de mémoire en hexadécimal et ASCII, similaire à la sortie de xxd .
Remarque : Cette fonctionnalité est expérimentale et peut changer de quelque manière que ce soit en fonction des commentaires des utilisateurs.
La fenêtre de trace de pile affiche l'état de chaque thread de programme. Les threads qui sont arrêtés peuvent être étendus pour afficher la trace de pile de ce thread.
Souvent, mais pas toujours, tous les fils sont arrêtés lorsqu'un point d'arrêt est touché. L'état d'un fil est affiché entre parenthèses après le nom du fil. Lorsqu'il est pris en charge par le débogueur sous-jacent, les threads peuvent être interrompus et poursuivis individuellement à l'intérieur de la fenêtre de trace de pile.
Un thread particulier, mis en évidence avec le groupe de surbrillance CursorLine est le thread "focalsé". Il s'agit du thread qui reçoit des commandes comme "Step in", "Step Out", "Continuer" et "Pause" dans la fenêtre de code. Le thread focalné peut être modifié manuellement pour "passer à" ce thread.
<CR> , ou double-cliquez avec la souris gauche pour développer / effondrer une trace de pile de thread ou utiliser le bouton Winbar.<CR> , ou double-cliquez avec la souris gauche sur un cadre de pile pour y sauter.vimspector#PauseContinueThread() pour faire une pause individuelle ou continuer le thread sélectionné.<leader><CR> ou vimspector#SetCurrentThread() pour définir le thread "FocusSé" sur celui actuellement sélectionné. Si la ligne sélectionnée est une trame de pile, définissez le thread focussé sur le thread de cette trame et sautez sur cette trame dans la fenêtre de code. La trace de pile est représentée par le tampon vimspector.StackTrace .
S'il y a des séances de débogage des enfants, comme lorsque le Debugee lance les processus enfants et l'adaptateur de débogage prend en charge le débogage multi-sessions, les threads de chaque session sont affichés séparément. La session actuellement active est celle qui est mise en évidence comme le cadre de thread / pile actuellement actif. Pour basculer le contrôle à une session différente, concentrez un thread au sein de cette session.
Remarque: Cela fait référence aux sessions créées en tant qu'enfants d'une session existante et ne doit pas être confondue avec [les séances de débogage multiple (parent)] [# Multiple-Debugging-Sessions].
:VimspectorShowOutput <category> . Utilisez l'achèvement de la ligne de commande pour voir les catégories. Si la fenêtre de sortie est fermée, une nouvelle peut être ouverte avec :VimspectorShowOutput <category> (utilisez Tab-Completion - wildmenu pour voir les options).
La fenêtre de la console est un tampon rapide, où cela est disponible, et peut être utilisé comme CLI interactif pour l'adaptateur de débogage. La prise en charge de cela varie entre les adaptateurs.
:VimspectorEval <expression> . L'achèvement est disponible avec certains adaptateurs de débogage.<CR>Remarque: Voir aussi les montres ci-dessus.
Si la fenêtre de sortie est fermée, une nouvelle peut être ouverte avec :VimspectorShowOutput Console .
Le tampon de l'invite de la console a son omnifunc défini sur une fonction qui calculera l'achèvement de la commande / expression actuelle. Ceci est trivialement utilisé avec <Ctrl-x><Ctrl-o> (voir :help ins-completion ), ou intégré à votre système d'achèvement préféré. Le type de fichier dans le tampon est défini sur VimspectorPrompt .
Pour YouCompleteMe, la configuration suivante fonctionne bien:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}Le fichier journal VimSpector contient une trace complète de la communication entre VimSpector et l'adaptateur de débogage. Il s'agit de la principale source d'informations de diagnostic lorsque quelque chose ne va pas, ce qui n'est pas un trace VIM.
Si vous voulez juste voir le fichier journal VimSpector, utilisez :VimspectorToggleLog , qui le réticulera dans une petite fenêtre (ne fonctionne pas sur Windows).
Vous pouvez voir des informations de débogage avec :VimspectorDebugInfo
Pour fermer le débogueur, utilisez:
Reset le bouton Winbar:VimspectorReset lorsque le winbar n'est pas disponible.call vimspector#Reset()Si le débogage est toujours en cours d'exécution lors de l'arrêt ou de la réinitialisation, certains adaptateurs de débogage vous permettent de spécifier ce qui devrait lui arriver lorsque vous terminez le débogage. En règle générale, le comportement par défaut est raisonnable, et c'est ce qui se passe la plupart du temps. Ce sont les valeurs par défaut selon DAP:
Certains adaptateurs de débogage vous permettent de choisir quoi faire lors de la déconnexion. Si vous souhaitez contrôler ce comportement, utilisez :VimspectorReset ou appelez vimspector#Reset( { 'interactive': v:true } ) . Si l'adaptateur de débogage offre un choix sur la question de savoir si la résiliation du débogage, vous serez invité à choisir. Il en va de même pour vimspector#Stop() qui peut prendre un argument: vimspector#Stop( { 'interactive': v:true } ) .
Remarque : Cette fonctionnalité est expérimentale et toute partie de celle-ci peut changer en réponse aux commentaires des utilisateurs.
VIMSpector prend en charge le démarrage d'un nombre arbitraire de séances de débogage. Chaque session est associée à un onglet d'interface utilisateur individuel. En règle générale, vous ne déboguez qu'une seule application et n'avez donc pas besoin de penser à cela, mais cette fonctionnalité avancée peut être utile si vous avez besoin de déboguer simultanément des applications indépendantes, ou plusieurs instances indépendantes de votre application.
À tout moment, il y a une seule session de racine "active". Les points d'arrêt sont associés à la session en cours et toutes les commandes d'interface utilisateur et d'API sont appliquées à la session actuellement active.
Lors de la commutation entre les sessions racine, les panneaux Breakpont pour la session précédente sont supprimés et les points d'arrêt de la session nouvellement activée sont affichés. Bien qu'il puisse être utile de voir des points d'arrêt pour toutes les sessions, cela peut être très déroutant.
Un flux de travail typique pourrait être:
:edit server.cc puis <F5> ). Cela démarre une session de débogage nommée d'après la configuration sélectionnée. Vous pouvez le renommer :VimspectorRenameSession server .:tabedit client.cc )client :: :VimspectorNewSession client ( client est maintenant la session active).client et commencez à déboguer avec <F5> . Vous avez maintenant 2 onglets VimSpector. Intuitivement, le wwitching vers un onglet particulier rendra sa session active. Vous pouvez également changer manuellement la session active avec :VimspectorSwitchToSession <name> .
Ainsi, en résumé, vous avez les installations suivantes:
VimspectorNewSession <name> Cela crée une nouvelle session et le rend actif. Le nom facultatif est utilisé à la place de celui généré lors du démarrage d'un lancement.VimspectorSwitchToSession <tab complete> .VimspectorRenameSession <new name>VimspectorDestroySession <name> . Vous ne pouvez pas détruire une session en cours d'exécution / active.vimspector#GetSessionName() utile pour mettre une ligne d'état. Il y a aussi vimspector#GetSessionID() pour les techniciens. Voici un exemple de la façon dont vous pouvez afficher le nom actuel de la session dans la statusline (voir :help statusline , ou la documentation de votre plugin de ligne d'état fantaisie).
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 ()} % ) Pour une introduction à la configuration de .vimspector.json , jetez un œil à la section de démarrage du site Web VimSpector.
Pour une explication complète, y compris la façon d'utiliser des variables, des substitutions et comment spécifier les points d'arrêt des exceptions, consultez les documents.
Le fichier de configuration JSON permet les commentaires de style C:
// comment to end of line .../* inline comment ... */Actuellement testé avec les adaptateurs de débogage suivants.
Exemple .vimspector.json (fonctionne avec vscode-cpptools et lldb-vscode . Pour lldb-vscode remplacez le nom de l'adaptateur par 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> "
}
}
// ...
}
} Remarque pour les utilisateurs de Windows: vous devez installer gdb.exe . Je recommande d'utiliser scoop install gdb . VIMSpector ne peut pas utiliser le débogueur Visual Studio en raison d'une licence.
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
"stopAtEntry" : true
}
}
}
}Selon le backend, vous devez activer manuellement la jolie impression de types complexes.
LLDB: La jolie impression est activée par défaut
GDB: Pour activer les jolies imprimantes GDB, pensez à l'extrait ci-dessous. Il ne suffit pas d'avoir set print pretty on dans votre .gdbinit!
{
"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
}
]
}
}
}
} La documentation CPPTools décrit comment attacher CPPTools à GDBServer à l'aide de miDebuggerAddress . Notez que lorsque vous faites cela, vous devez utiliser la "request": "attach" .
Si vous vous sentez fantaisiste, consultez le guide de référence pour un exemple de la mise en place et de la connexion à distance.
CodellDB est supérieur à Vscode-Cpptools de plusieurs façons sur MacOS au moins.
Voir Rust.
Une alternative consiste à utiliser lldb-vscode , qui est livrée avec LLVM. Voici comment :
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 est soutenue par tout débogueur basé sur GDB / LLDB. Cela fonctionne donc bien avec vscode-cpptools et lldb-vscode ci-dessus. Cependant, le soutien à la rouille est le meilleur dans CodeLLDB .
./install_gadget.py --enable-rust ou :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" - c'est invalide. Utilisez plutôt "request": "launch", "custom": true . Parce que les raisonscargo est effectuée dans la folie JavaScript VScode, donc n'est pas prise en charge."request": custom ; Voir le point sur le lancement "personnalisé" ci-dessusstep-into pour les fonctions de bibliothèque standard) peut être effectué en ajoutant "sourceMap": { "from_path" : "to_path" } . "from_path" se trouve dans la fenêtre de démontage en montant dans la trace de pile; "to_path" est juste votre chemin de bibliothèque standard installé localement pour la chaîne d'outils actuelle. Le débogage de Jai fonctionne bien avec l'un des autres débuggeurs autochtones. Je recommande CodellDB, mais CPPTools fonctionne également.
Exemple:
{
"$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
Installez avec install_gadget.py --enable-python ou :VimspectorInstall debugpy , nécessite idéalement un compilateur de travail et les en-têtes / libs de développement Python pour créer une extension C Python pour les performances.
Remarque : Debugpy ne prend plus en charge Python 2. Afin de continuer à déboguer les applications Python 2, utilisez l'adaptateur debugpy-python2 après l'installation du gadget debugpy-python2 .
Options complètes: 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> "
}
}
...
}
}Afin d'utiliser le débogage à distance avec Debugpy, vous devez connecter VIMSpector directement à l'application qui est en cours de débogage. C'est facile, mais c'est un peu différent de la façon dont nous configurons normalement les choses. Plus précisément, vous devez:
--listen . Voir la documentation Debugpy pour plus de détails.{
"configurations" : {
"Python Attach" : {
"adapter" : " multi-session " ,
"filetypes" : [ " python " ], // optional
"configuration" : {
"request" : " attach " ,
"pathMappings" : [
// mappings here (optional)
]
}
}
}
} Voir les détails de la configuration de lancement pour l'explication de choses comme pathMappings .
La documentation supplémentaire, y compris la façon de procéder lorsque la machine distante ne peut être contactée que via SSH est fournie par Debugpy.
Si vous vous sentez fantaisiste, vérifiez le guide de référence pour un exemple de la mise en place et de la connexion à distance.
Afin de continuer à déboguer les applications Python 2, assurez-vous d'installer le gadget debugpy-python2 (par exemple --force-enable-python2 ou :VimspectorInstall debugpy-python2 ), puis modifiez votre configuration à utiliser:
{
"configurations" : {
"Python Attach" : {
"adapter" : " debugpy-python2 " ,
// ...
}
}
}
pour examen
Voir ma fourche de tclprodebug pour les instructions.
Installer avec install_gadget.py --force-enable-csharp ou :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" : {}
}
}
}
}Exige:
install_gadget.py --enable-go ou :VimspectorInstall delvego 1.16 ou ultérieure (ymmv sur les versions antérieures)Cela utilise le support DAP intégré au débogueur Delve
{
"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 "
}
}
}
}Utilisez des variables pour configurer ce qui suit:
dlvFlags : (String) Arguments de ligne de commande supplémentaires à passer pour plongerLe débogueur (Delve) est lancé dans une fenêtre de terminal afin que vous puissiez voir sa sortie et transmettre une entrée au débogage.
Voir les documents VScode-Go pour les options de lancement complètes. Oui, il semble que ce soit le seul endroit où ils sont documentés (apparemment, ils ne sont pas documentés par Delve lui-même).
Les documents VScode-Go ont également des informations de dépannage utiles
Exige:
install_gadget.py --enable-go ou :VimspectorInstall vscode-gogo get -u github.com/go-delve/delve/cmd/dlvdlvToolPathRemarque: VIMSpector utilise l'adaptateur de débogage VScode-Go "Legacy" plutôt que le support DAP "intégré" dans Delve. Vous pouvez suivre # 186 pour cela.
{
"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" ]
}
}
}
}Voir les documents VScode-Go pour le dépannage des informations
Cela utilise le php-debug, voir https://marketplace.visualstudio.com/items?itemname=felixfbecker.php-debug
Exige:
install_gadget.py --force-enable-php ou :VimspectorInstall vscode-php-debug zend_extension =xdebug.so
xdebug.remote_enable =on
xdebug.remote_handler =dbgp
xdebug.remote_host =localhost
xdebug.remote_port =9000 Remplacez localhost par l'IP de votre poste de travail.
alternative paresseuse
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
}
}
}
} Ajouter XDEBUG_SESSION_START=xdebug à votre chaîne de requête
curl "http://localhost?XDEBUG_SESSION_START=xdebug"
ou utilisez l'extension XDebug Helper mentionnée précédemment (qui définit un cookie XDEBUG_SESSION )
export XDEBUG_CONFIG= " idekey=xdebug "
php < path to script > Cela utilise VScode-js-debug, le débogueur qui est également utilisé dans VScode. Pour des configurations supplémentaires, consultez la documentation ici.
Pour installer vscode-js-debug, exécutez VimspectorInstall vscode-js-debug à partir de VIM ou exécutez le script d'installation install_gadget.py --force-enable-node . Il existe plusieurs exemples que vous pouvez vérifier. Trouvez-les sous support/test/node/simple , support/test/node/multiprocess et support/test/node/typescript . Une configuration typique pour le débogage de typescript ressemble à ceci:
{
"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 prend en charge un certain nombre de "types" différents et peut faire des choses qui peuvent ou non fonctionner. Le champ type n'est malheureusement pas documenté, mais les valeurs valides sont définies ici dans l'énumération DebugType.
VIMSpector n'a été testé qu'avec le type pwa-node .
Notez également que pour une raison quelconque, cet adaptateur de débogage nous oblige toujours à commencer plusieurs séances de débogage. Pour un utilisateur, cela ne devrait rien changer (à part peut-être une trace de pile légèrement déroutante). Mais cela rend les choses plus compliquées et il peut donc y avoir des bugs subtils.
Cela utilise le débogueur Chrome / Firefox (ils sont très similaires), voir https://marketplace.visualstudio.com/items?itemname=msjsdiag.debugger-for-chrome et https://marketplace.visualstudio.com/items?itemname = Firefox-devtools.vscode-firefox-debug, respectivement.
Il vous permet de déboguer des scripts à l'intérieur de Chrome à partir de l'intérieur de VIM.
./install_gadget.py --force-enable-chrome ou :VimspectorInstall debugger-for-chrome./install_gadget.py --force-enable-firefox ou :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 fonctionne bien avec le serveur de débogage Java, qui s'exécute en tant que plugin JDT.LS (Java Language Server), plutôt que comme un adaptateur de débogage autonome.
VIMSpector n'est pas dans le domaine des serveurs de langage, uniquement les adaptateurs de débogage, ce qui signifie que vous avez besoin d'un plugin d'éditeur de protocole de serveur de langage compatible pour utiliser Java. Je recommande à YouCompleteMe, qui a une prise en charge complète pour JDT.LS, et surtout un moyen trivial de charger l'adaptateur de débogage et de l'utiliser avec VimSpector.
Lorsque vous utilisez le serveur de débogage Java, VIMSpector prend en charge la fonction Remplacer le code chaud. Par défaut, lorsque les fichiers de classe sous-jacents changent, VIMSpector demande à l'utilisateur s'il souhaite recharger ces classes à l'exécution.
Ce comportement peut être personnalisé:
let g:vimspector_java_hotcodereplace_mode = 'ask' - la valeur par défaut, demandez à l'utilisateur pour chaque rechargement.let g:vimspector_java_hotcodereplace_mode = 'always' - ne demandez pas, rechargez toujourslet g:vimspector_java_hotcodereplace_mode = 'never' - ne demandez pas, ne rechargez jamaisinstall_gadget.py --force-enable-java <other options...> ou :VimspectorInstall java-debug-adaptervscode-java , par exemple: {
"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> , pas un adaptateur spécifique. par exemple dans .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> pour démarrer le serveur de débogage et lancer vimSpector, par exemple dans ~/.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>
Vous pouvez ensuite utiliser <Leader><F5> pour commencer le débogage plutôt que <F5> .
Si vous voyez "Impossible d'obtenir le port DAP - JDT.LS est-il initialisé?", Essayez d'exécuter :YcmCompleter ExecuteCommand vscode.java.startDebugSession et notez la sortie. Si vous voyez une erreur comme ResponseFailedException: Request failed: -32601: No delegateCommandHandler for vscode.java.startDebugSession , assurez-vous que:
g:ycm_java_jdtls_extension_path est défini dans .vimrc ou avant le démarrage de YCMPour les arguments de lancement, consultez le document VScode.
Voir ce problème pour plus d'informations.
LUA est pris en charge via local-lua-debugger-vscode. Ce débogueur utilise STDIO pour communiquer avec le processus de fonctionnement, donc les appels à io.read causeront des problèmes.
./install_gadget.py --enable-lua ou :VimspectorInstall local-lua-debugger-vscodesupport/test/lua/simple et 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} " ]
}
}
}
}Il y a une prise en charge très limitée pour la personnalisation de l'interface utilisateur.
VIMSector utilise les panneaux suivants en interne. S'ils sont définis avant que Vimsector ne les utilise, ils ne seront pas remplacés. Donc, pour personnaliser les panneaux, définissez-les dans votre vimrc .
| Signe | Description | Priorité |
|---|---|---|
vimspectorBP | Point de rupture de ligne | 9 |
vimspectorBPCond | Point de rupture de ligne conditionnelle | 9 |
vimspectorBPLog | Logpoint | 9 |
vimspectorBPDisabled | Point d'arrêt désactivé | 9 |
vimspectorPC | Counter de programme (c.-à-d. Ligne actuelle) | 200 |
vimspectorPCBP | Compteur de programmes et point d'arrêt | 200 |
vimspectorNonActivePC | Compteur de programme pour fil non focalisé | 9 |
vimspectorCurrentThread | Thread concentré dans la vue de trace de pile | 200 |
vimspectorCurrentFrame | Frame de pile actuelle dans la vue de trace de pile | 200 |
Les symboles par défaut sont l'équivalent de quelque chose comme les suivants:
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 Si les panneaux ne s'affichent pas correctement, votre police ne contient probablement pas ces glyphes. Vous pouvez facilement les changer en définissant le signe dans votre VIMRC. Par exemple, vous pouvez mettre cela dans votre vimrc pour utiliser des symboles ASCII simples:
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 De nombreux plugins différents fournissent des panneaux à diverses fins. Les exemples incluent des panneaux de diagnostic pour les erreurs de code, etc. VIM ne fournit qu'une seule priorité pour déterminer quel signe doit être affiché lorsque plusieurs signes sont placés sur une seule ligne. Si vous constatez que d'autres signes interfèrent avec VimSpector's (ou vice-versa), vous pouvez personnaliser la priorité utilisée par VimSpector en définissant le dictionnaire suivant:
let g: vimspector_sign_priority = {
' <sign-name> ' : <priority> ,
}Par exemple:
let g: vimspector_sign_priority = {
' vimspectorBP ' : 3 ,
' vimspectorBPCond ' : 3 ,
' vimspectorBPLog ' : 3 ,
' vimspectorBPDisabled ' : 3 ,
' vimspectorNonActivePC ' : 3 ,
' vimspectorPC ' : 999 ,
' vimspectorPCBP ' : 999 ,
}Toutes les clés sont facultatives. Si un signe n'est pas personnalisé, la priorité par défaut qu'il a utilisée (comme indiqué ci-dessus).
Voir :help sign-priority . La priorité par défaut est de 10, les nombres plus grands remplacent les plus petits.
Remarque : Le signe vimspectorNonActivePC par défaut n'ajoute aucun texte à la colonne de signe, il ajoute simplement un point fort de ligne afin que vous puissiez voir les lignes où d'autres threads ou processus sont actuellement arrêtés. En conséquence, ce signe devrait normalement fusionner avec tout signe qui ajoute un symbole (comme un signe de point d'arrêt). VIM ne fera que fusionner les propriétés des signes avec la même priorité, donc si vous modifiez les priorités par défaut, il est recommandé que:
vimspectorBP , vimspectorBPCond , etc.) ont la même priorité.vimspectorNonActivePC cette même prioritévimspectorPC , vimspectorPCBP , etc.) a une priorité plus élevée. Remarque: Ce point de personnalisation n'est actuellement pas en mesure et peut changer à tout moment.
Parfois, l'adaptateur de débogage fournit des conseils sur la façon dont l'interface utilisateur doit afficher certaines choses. Cela inclut des cadres de pile, des variables, etc.
VIMSpector fournit un moyen simple de personnaliser la façon dont ceux-ci sont affichés, en définissant des valeurs dans le dictionnaire g:vimsepctor_presentation_hint_hl .
Les clés suivantes sont prises en charge avec le groupe de surbrillance par défaut mentionné.
| Groupe | Clé | Usage | Défaut |
|---|---|---|---|
| tous | normal | Tout ce qui n'est pas couvert ci-dessous | Normal |
| Trace de pile | emphasize | Mettre l'accent sur les sources dans la trace de pile | Title |
| Trace de pile | deemphasize | Désigne les sources de trace de pile | Conceal |
| Trace de pile | label | empiler les cadres qui sont des "étiquettes", ne représentant pas les cadres réels | NonText |
| Trace de pile | subtle | empiler les cadres qui sont internes ou pas intéressants | Conceal |
| Portées | arguments | Arguments de fonction Portée | Title |
| Portées | locals | Portée des variables locales | Title |
| Portées | registers | Portée des registres | Title |
| Variables | property | Arguments de fonction Portée | Identifier |
| Variables | method | Portée des variables locales | Function |
| Variables | class | Portée des registres | Type |
| Variables | data | Portée des registres | String |
De plus, toute valeur fournie dans la VariablePresentationHint DAP peut être définie qui sera utilisée si elle est fournie par l'adaptateur de débogage.
Un exemple idiot; Les valeurs par défaut devraient probablement être OK pour la plupart des scehemes de couleur:
let g: vimspector_presentation_hint_hl = {
' normal ' : ' Identifier ' ,
' label ' : ' Title ' ,
}Veuillez noter : cette API de personnalisation est instable , ce qui signifie qu'elle peut changer à tout moment. Je m'efforcerai de réduire l'impact de cela et d'annoncer des changements dans Gitter.
Les options suivantes contrôlent les tailles par défaut des fenêtres de l'interface utilisateur (toutes sont des numéros)
g:vimspector_sidebar_width (par défaut: 50 colonnes): la largeur dans les colonnes des fenêtres de l'utilitaire gauche (variables, montres, trace de pile)g:vimspector_bottombar_height (par défaut 10 lignes): la hauteur en lignes de la fenêtre de sortie sous la fenêtre de code.Exemple:
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.
Exemple:
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? Vous n’en avez pas besoin. 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 " : " "
}
}
} }
