vimspector
1.0.0
Para obter um tutorial e uma visão geral do uso, dê uma olhada no site do Vimspector.
Para obter uma explicação detalhada do formato .vimspector.json , consulte o guia de referência.
O plugin é um depurador gráfico Vim capaz para vários idiomas. Ele é testado principalmente para C++, Python e TCL, mas em teoria oferece suporte a qualquer linguagem compatível com o Visual Studio Code (mas consulte as advertências).
O site do Vimspector tem uma visão geral da IU, junto com instruções básicas para configuração e configuração.
Mas, por enquanto, aqui está uma captura de tela (bastante antiga) do Vimspector depurando o Vim:
E algumas breves demonstrações:
<Plug>VimspectorBalloonEval )A tabela a seguir lista os idiomas "integrados" (juntamente com suas dependências de tempo de execução). Eles são categorizados por seu nível de suporte:
Tested : Totalmente suportado, os testes de regressão do Vimspector cobrem-nosSupported : Totalmente suportado, usado com frequência e testado manualmenteExperimental : Funcionando, mas não é usado com frequência e raramente testadoLegacy : não é mais compatível, migre sua configuraçãoRetired : não está mais incluído ou com suporte.| Idiomas | Status | Alternar (para install_gadget.py ) | Adaptador (para :VimspectorInstall ) | Dependências |
|---|---|---|---|---|
| C, C++, Ferrugem, Jai, etc. | Testado | --all ou --enable-c (ou cpp) | vscode-cpptools | mono-núcleo |
| C, C++, Ferrugem, Jai, etc. | Testado | --enable-rust , --enable-c , etc. | CódigoLLDB | nenhum |
| Pitão | Testado | --all ou --enable-python | depurar | Pitão 3 |
| Ir | Testado | --enable-go | aprofundar | Vá para 1.16+ |
| TCL | Suportado | --all ou --enable-tcl | tclpro | TCL 8.5 |
| Concha Bourne | Suportado | --all ou --enable-bash | vscode-bash-depuração | Bateu v?? |
| Lua | Testado | --all ou --enable-lua | local-lua-debugger-vscode | Nó >=12.13.0, Npm, interpretador Lua |
| Node.js | Suportado | --force-enable-node | vscode-js-depuração | Nó >= 18 |
| JavaScript | Suportado | --force-enable-chrome | depurador para Chrome | Cromo |
| JavaScript | Suportado | --force-enable-firefox | vscode-firefox-debug | Firefox |
| Java | Suportado | --force-enable-java | vscode-java-debug | Plug-in LSP compatível (veja mais tarde) |
| PHP | Experimental | --force-enable-php | vscode-php-depuração | Nó, PHP, XDEBUG |
| C# (núcleo dotnet) | Testado | --force-enable-csharp | netcoredbg | Núcleo DotNet |
| F#, VB, etc. | Suportado | --force-enable-[fsharp,vbnet] | netcoredbg | Núcleo DotNet |
| Vá (legado) | Legado | --enable-go | vscode-go | Nó, vá, aprofunde |
| Pitão 2 | Legado | --force-enable-python2 | debugpy-python2 | Pitão 2.7 |
O Vimspector deve funcionar para qualquer adaptador de depuração que funcione no Visual Studio Code.
Para usar o Vimspector com uma linguagem que não é "integrada", consulte esta página wiki.
Existem 2 métodos de instalação:
:help packages .packadd! vimspector para o seu .vimrc.vimspector.json ou defina g:vimspector_configurations ) - consulte o guia de referênciaVerifique as dependências
Consulte a documentação do gerenciador de plugins e instale o plugin. Para Vundle, use:
Plugin ' puremourning/vimspector 'Instale alguns 'gadgets' (adaptadores de depuração) - veja aqui os comandos de instalação e selecione os gadgets para instalar
Configure os perfis de depuração do seu projeto (crie .vimspector.json ou defina g:vimspector_configurations ) - consulte o guia de referência
As seções a seguir expandem a breve visão geral acima.
O Vimspector requer:
Quais versões do Linux? Eu testo apenas no Ubuntu 20.04 e posterior e no RHEL 7.
O neovim não implementa balões de foco do mouse. Em vez disso, há o mapeamento <Plug>VimspectorBalloonEval . Não há mapeamento padrão para isso, então recomendo algo assim para obter a exibição de variáveis em um pop-up:
" 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> VimspectorBalloonEvalOs seguintes recursos não estão implementados no Windows:
Se você quiser apenas experimentar o vimspector sem alterar a configuração do vim, existem exemplos de projetos para vários idiomas em support/test , incluindo:
Para testar um deles, faça cd no diretório e execute:
vim -Nu /path/to/vimspector/tests/vimrc --cmd "let g:vimspector_enable_mappings='HUMAN'"
Em seguida, pressione <F5> .
Há também um projeto C++ em tests/testdata/cpp/simple/ com um Makefile que pode ser usado para verificar se tudo está funcionando. Isso é usado pelos testes de regressão no CI, portanto sempre deve funcionar e é uma boa maneira de verificar se o problema é sua configuração e não um bug.
Existem muitos gerenciadores de plugins do Vim, e não vou declarar uma preferência específica, então se você optar por usar um, siga a documentação do gerenciador de plugins. Por exemplo, para Vundle, use:
Plugin ' puremourning/vimspector 'Se você ainda não usa um gerenciador de plugins, instale o vimspector como um pacote Vim clonando este repositório no caminho do seu pacote, assim:
$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector
.vimrc , por exemplo, para habilitar os mapeamentos padrão: let g: vimspector_enable_mappings = ' HUMAN '.vimrc após configurar o vimspector: packadd! vimspector
Consulte support/doc/example_vimrc.vim para obter um exemplo mínimo.
Vimspector é um cliente genérico para adaptadores de depuração. Adaptadores de depuração (chamados de 'gadgets' ou 'adaptadores') são o que realmente fazem o trabalho de conversar com os depuradores reais.
Para que o Vimspector seja útil, você precisa ter alguns adaptadores instalados.
Existem algumas maneiras de fazer isso:
:VimspectorInstall <adapter> <args...> (use TAB wildmenu para ver as opções, também aceita qualquer opção install_gadget.py )python3 install_gadget.py <args> (use --help para ver todas as opções):VimspectorUpdate para instalar as versões mais recentes suportadas dos gadgets.Aqui está uma demonstração de como fazer algumas instalações e uma atualização:
Tanto install_gadget.py quanto :VimspectorInstall fazem o mesmo conjunto de coisas, embora os comportamentos padrão sejam um pouco diferentes. Para idiomas suportados, eles irão:
gadgetDir para a plataforma.Por exemplo, para instalar o adaptador de depuração testado para um idioma, execute:
| Para instalar | Roteiro | Comando |
|---|---|---|
<adapter> | :VimspectorInstall <adapter> | |
<adapter1> , <adapter2> , ... | :VimspectorInstall <adapter1> <adapter2> ... | |
<language> | ./install_gadget.py --enable-<language> ... | :VimspectorInstall --enable-<language> ... |
| Adaptadores suportados | ./install_gadget.py --all | :VimspectorInstall --all |
| Adaptadores suportados, mas não TCL | ./install_gadget.py --all --disable-tcl | :VimspectorInstall --all --disable-tcl |
| Adaptadores suportados e experimentais | ./install_gadget.py --all --force-all | :VimspectorInstall --all |
| Adaptador para configuração de depuração específica | Sugerido pelo Vimspector ao iniciar a depuração |
:VimspectorInstall executa install_gadget.py em segundo plano com algumas das opções padrão.
:VimspectorUpdate executa install_gadget.py para reinstalar (ou seja, atualizar) quaisquer gadgets já instalados em seu .gadgets.json .
A saída é mínima, para ver a saída completa adicione --verbose ao comando, como em :VimspectorInstall --verbose ... ou :VimspectorUpdate --verbose ... .
Se a instalação for bem-sucedida, a janela de saída será fechada (e a saída será perdida para sempre). Use um ! para mantê-lo aberto (por exemplo :VimspectorInstall! --verbose --all ou :VimspectorUpdate! (etc.).
Se você souber antecipadamente quais gadgets deseja instalar, por exemplo, para poder reproduzir sua configuração do controle de origem, poderá definir g:vimspector_install_gadgets como uma lista de gadgets. Isso será usado quando:
:VimspectorInstall sem argumentos ou:VimspectorUpdatePor exemplo:
let g: vimspector_install_gadgets = [ ' debugpy ' , ' vscode-cpptools ' , ' CodeLLDB ' ] Por padrão, install_gadget.py substituirá seu .gadgets.json pelo conjunto de adaptadores recém-instalados, enquanto :VimspectorInstall irá atualizá- lo, substituindo apenas adaptadores recentemente alterados ou instalados.
Se você quiser apenas adicionar um novo adaptador usando o script sem destruir os existentes, adicione --update-gadget-config , como em:
$ ./install_gadget.py --enable-tcl
$ ./install_gadget.py --enable-rust --update-gadget-config
$ ./install_gadget.py --enable-java --update-gadget-config Se você deseja manter configurations fora do repositório vimspector (isso pode ser útil se você tiver gadgets personalizados ou configurações globais), você pode dizer ao instalador para usar um basedir diferente e definir g:vimspector_base_dir para apontar para esse diretório, por exemplo :
$ ./install_gadget.py --basedir $HOME /.vim/vimspector-config --all --force-all Em seguida, adicione isto ao seu .vimrc :
let g: vimspector_base_dir = expand ( ' $HOME/.vim/vimspector-config ' ) Ao usar :VimspectorInstall , a configuração g:vimspector_base_dir é respeitada, a menos que --basedir seja adicionado manualmente (não recomendado).
Veja --help para mais informações sobre as diversas opções.
Se o idioma que você deseja depurar não estiver na lista de suporte acima, provavelmente você ainda poderá fazê-lo funcionar, mas será mais trabalhoso.
Basicamente, você precisa obter uma instalação funcional do adaptador de depuração, descobrir como iniciá-lo e configurá-lo em uma entrada adapters em seu .vimspector.json ou em .gadgets.json ou em g:vimspector_adapters .
A maneira mais simples na prática é instalar ou iniciar o Visual Studio Code e usar seu gerenciador de extensões para instalar a extensão relevante. Você pode então configurar o adaptador manualmente na seção de adapters do seu .vimspector.json ou em gadgets.json ou em g:vimspector_adapters .
PRs são sempre bem-vindos para adicionar idiomas suportados (o que se traduz aproximadamente em atualizar python/vimspector/gadgets.py e testá-lo).
O Vimspector usa o seguinte diretório por padrão para procurar um arquivo chamado .gadgets.json : </path/to/vimspector>/gadgets/<os> .
Este caminho é exposto como a variável vimspector ${gadgetDir} . Isso é útil para configurar linhas de comando de gadgets.
Onde os é um dos:
macoslinuxwindows (no entanto, observe: o Windows não é compatível) O formato é o mesmo de .vimspector.json , mas apenas a chave adapters é usada:
Exemplo:
{
"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 "
}
}
} O arquivo do gadget é gravado automaticamente por install_gadget.py (ou :VimspectorInstall ).
O Vimspector também carregará quaisquer arquivos correspondentes: </path/to/vimspector>/gadgets/<os>/.gadgets.d/*.json . Eles têm o mesmo formato de .gadgets.json , mas não são substituídos ao executar install_gadget.py .
Depois de atualizar o código do Vimspector (via git pull ou qualquer outro gerenciador de pacotes), execute :VimspectorUpdate para atualizar quaisquer gadgets já instalados.
A motivação é que a depuração no Vim é uma experiência horrível, principalmente se você usar vários idiomas. Sem mais o pyclewn e o plugin termdebug integrado limitado ao gdb, eu queria explorar as opções.
Embora o Language Server Protocol seja bem conhecido, o Debug Adapter Protocol é menos conhecido, mas atinge um objetivo semelhante: API independente de linguagem que abstrai depuradores de clientes.
O objetivo deste projeto é fornecer uma experiência de depuração simples, mas eficaz no Vim para vários idiomas, aproveitando os adaptadores de depuração que estão sendo criados para o Visual Studio Code.
A capacidade de fazer depuração remota é obrigatória. Isso é fundamental para meu fluxo de trabalho, portanto, incorporá-lo à experiência de depuração é uma das principais metas do projeto. Portanto, o vimspector tem suporte de primeira classe para executar programas remotamente e anexar a eles. Este suporte é exclusivo do vimspector e além de (complementar) qualquer suporte em adaptadores de depuração reais.
Vimspector é uma UI vim sobre o Debug Adapter Protocol. Ele foi projetado para ser de alto nível e conveniente para tarefas diárias de depuração.
Vimspector não é:
O Vimspector é um trabalho em andamento e qualquer feedback/contribuição é mais que bem-vindo.
O backlog pode ser visualizado no Trello.
O plugin é atualmente experimental . Isso significa que qualquer parte dele pode (e provavelmente irá) mudar, incluindo coisas como:
No entanto, comprometo-me a fazer isso apenas nos casos mais extremos e a anunciar tais mudanças no Gitter com bastante antecedência. Não há nada mais irritante do que coisas quebrando em você. Eu entendo isso.
Uma mensagem do autor sobre a motivação deste plugin:
Muitos ambientes de desenvolvimento possuem um depurador integrado. Passo muito tempo no Vim. Eu faço todo o meu desenvolvimento no Vim e até personalizei meus fluxos de trabalho para construir código, executar testes etc.
Por muitos anos eu tenho observado, amigos e colegas têm escrito
printf,puts,Eu realmente acredito que ambientes de depuração gráficos e interativos são a melhor maneira de entender e raciocinar sobre códigos desconhecidos e familiares, e que a falta de acesso simples e pronto a um depurador é um enorme buraco de produtividade oculto para muitos.
Não me interpretem mal, eu sei que existem literalmente milhões de desenvolvedores por aí que são mais do que competentes em desenvolver sem um depurador gráfico, mas afirmo que se eles tivessem a capacidade de simplesmente pressionar uma tecla e entrar no depurador, seria seria mais rápido e agradável do que apenas a compreensão do código cerebral.
Criei o Vimspector porque acho frustrante mudar de ferramentas.
gdbpara c++,pdbpara python, etc. Cada um tem sua própria sintaxe. Cada um com seu próprio léxico. Cada um com suas próprias fraquezas.Eu projetei o sistema de configuração de tal forma que a configuração possa ser comprometida com o controle de origem para que funcione apenas para qualquer um de seus colegas, amigos, colaboradores ou estranhos.
Tornei a depuração remota um recurso de primeira classe porque esse é o principal caso de uso para mim em meu trabalho.
Com o Vimspector, posso simplesmente pressionar
<F5>em todas as linguagens nas quais desenvolvo e depurar local ou remotamente usando exatamente o mesmo fluxo de trabalho, mapeamentos e UI. Eu integrei isso ao meu Vim de forma que posso apertar um botão e executar o teste sob o cursor no Vimspector . Esse tipo de integração melhorou enormemente meu fluxo de trabalho e produtividade. Até tornou o processo de aprendizagem de uma nova base de código... divertido.- Ben Jackson, criador.
Apache 2.0
Direitos autorais © 2018 Ben Jackson
Se você gosta tanto do Vimspector que deseja gastar seu suado dinheiro, considere doar para uma das seguintes instituições de caridade, que são significativas para o autor do Vimspector (em ordem de preferência):
Por padrão, o vimspector não altera nenhum dos seus mapeamentos. Os mapeamentos são muito pessoais e, portanto, você deve descobrir o que gosta e usar os poderosos recursos de mapeamento do vim para definir seus próprios mapeamentos. Para esse fim, o Vimspector define os seguintes mapeamentos <Plug> :
| Mapeamento | Função | API |
|---|---|---|
<Plug>VimspectorContinue | Ao depurar, continue. Caso contrário, comece a depuração. | vimspector#Continue() |
<Plug>VimspectorStop | Pare de depurar. | vimspector#Stop() |
<Plug>VimpectorRestart | Reinicie a depuração com a mesma configuração. | vimspector#Restart() |
<Plug>VimspectorPause | Pausar o depurado. | vimspector#Pause() |
<Plug>VimspectorBreakpoints | Mostrar/ocultar a janela de pontos de interrupção | vimspector#ListBreakpoints() |
<Plug>VimspectorToggleBreakpoint | Alterna o ponto de interrupção da linha na linha atual. | vimspector#ToggleBreakpoint() |
<Plug>VimspectorToggleConditionalBreakpoint | Alternar ponto de interrupção de linha condicional ou logpoint na linha atual. | vimspector#ToggleBreakpoint( { trigger expr, hit count expr } ) |
<Plug>VimspectorAddFunctionBreakpoint | Adicione um ponto de interrupção de função para a expressão sob o cursor | vimspector#AddFunctionBreakpoint( '<cexpr>' ) |
<Plug>VimspectorGoToCurrentLine | Redefinir o contador do programa atual para a linha atual | vimspector#GoToCurrentLine() |
<Plug>VimspectorRunToCursor | Corra para o cursor | vimspector#RunToCursor() |
<Plug>VimspectorStepOver | Passar por cima | vimspector#StepOver() |
<Plug>VimspectorStepInto | Entre | vimspector#StepInto() |
<Plug>VimspectorStepOut | Sair do escopo da função atual | vimspector#StepOut() |
<Plug>VimspectorDisassemble | Mostrar desmontagem. Habilitar passo de instrução | vimspector#ShowDisassembly() |
<Plug>VimspectorUpFrame | Subir um quadro na pilha de chamadas atual | vimspector#UpFrame() |
<Plug>VimspectorDownFrame | Mover para baixo um quadro na pilha de chamadas atual | vimspector#DownFrame() |
<Plug>VimspectorJumpToNextBreakpoint | Mova o cursor para o próximo ponto de interrupção no arquivo atual | vimspector#JumpToNextBreakpoint() |
<Plug>VimspectorJumpToPreviousBreakpoint | Mova o cursor para o ponto de interrupção anterior no arquivo atual | vimspector#JumpToPreviousBreakpoint() |
<Plug>VimspectorJumpToProgramCounter | Mova o cursor para o contador do programa no quadro atual | vimspector#JumpToProgramCounter() |
<Plug>VimspectorBalloonEval | Avalie a expressão sob o cursor (ou visual) no pop-up | interno |
Eles mapeiam aproximadamente 1-1 com as funções da API abaixo.
Por exemplo, se você deseja que <F5> inicie/continue a depuração, adicione-o a algum local apropriado, como seu vimrc (dica: run :e $MYVIMRC ).
nmap <F5> <Plug> VimspectorContinueAlém disso, muitos usuários provavelmente desejam ativar apenas determinados mapeamentos do Vimspector enquanto a depuração estiver ativa. Isso também é possível, embora exija a escrita de algum vimscipt.
Dito isto, muitas pessoas estão familiarizadas com depuradores específicos, portanto, os seguintes mapeamentos podem ser habilitados definindo g:vimspector_enable_mappings para o valor especificado.
Para usar mapeamentos semelhantes ao Visual Studio, adicione o seguinte ao seu vimrc antes de carregar vimspector :
let g: vimspector_enable_mappings = ' VISUAL_STUDIO '| Chave | Mapeamento | Função |
|---|---|---|
F5 | <Plug>VimspectorContinue | Ao depurar, continue. Caso contrário, comece a depuração. |
Shift F5 | <Plug>VimspectorStop | Pare de depurar. |
Ctrl Shift F5 | <Plug>VimspectorRestart | Reinicie a depuração com a mesma configuração. |
F6 | <Plug>VimspectorPause | Pausar o depurado. |
F8 | <Plug>VimspectorJumpToNextBreakpoint | Ir para o próximo ponto de interrupção no arquivo atual. |
Shift F8 | <Plug>VimspectorJumpToPreviousBreakpoint | Ir para o ponto de interrupção anterior no arquivo atual. |
F9 | <Plug>VimspectorToggleBreakpoint | Alterna o ponto de interrupção da linha na linha atual. |
Shift F9 | <Plug>VimspectorAddFunctionBreakpoint | Adicione um ponto de interrupção de função para a expressão sob o cursor |
F10 | <Plug>VimspectorStepOver | Passar por cima |
Ctrl F10 | <Plug>VimspectorRunToCursor | Correr para o cursor* |
F11 | <Plug>VimspectorStepInto | Entre |
Shift F11 | <Plug>VimspectorStepOut | Sair do escopo da função atual |
Alt 8 | <Plug>VimspectorDisassemble | Mostrar desmontagem |
NOTA: Alguns mapeamentos, como as teclas ctrl e F, podem não funcionar dependendo do seu terminal, teclado, sistema de janelas e todo tipo de outras coisas. Veja :help modifyOtherKeys e outras fontes. Se você não conseguir fazer isso funcionar, basta usar os mapeamentos do "modo humano".
Se, como eu, você tem apenas 2 mãos e 10 dedos, provavelmente não gosta das teclas Ctrl-Shift-F. Além disso, se você estiver executando em um terminal, há uma possibilidade real de terminfo estar errado para teclas F deslocadas, principalmente se seu TERM for screen-256color . Se esses problemas (número de mãos, variáveis TERM ) não puderem ser corrigidos, tente os seguintes mapeamentos, adicionando o seguinte antes de carregar o vimspector :
let g: vimspector_enable_mappings = ' HUMAN '| Chave | Mapeamento | Função |
|---|---|---|
F5 | <Plug>VimspectorContinue | Ao depurar, continue. Caso contrário, comece a depuração. |
F3 | <Plug>VimspectorStop | Pare de depurar. |
F4 | <Plug>VimspectorRestart | Reinicie a depuração com a mesma configuração. |
F6 | <Plug>VimspectorPause | Pausar o depurado. |
F9 | <Plug>VimspectorToggleBreakpoint | Alterna o ponto de interrupção da linha na linha atual. |
<leader>F9 | <Plug>VimspectorToggleConditionalBreakpoint | Alternar ponto de interrupção de linha condicional ou logpoint na linha atual. |
F8 | <Plug>VimspectorAddFunctionBreakpoint | Adicione um ponto de interrupção de função para a expressão sob o cursor |
<leader>F8 | <Plug>VimspectorRunToCursor | Corra para o cursor |
F10 | <Plug>VimspectorStepOver | Passar por cima |
F11 | <Plug>VimspectorStepInto | Entre |
F12 | <Plug>VimspectorStepOut | Sair do escopo da função atual |
Além disso, recomendo adicionar um mapeamento ao <Plug>VimspectorBalloonEval , nos modos normal e visual, por exemplo:
" 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> VimspectorBalloonEvalVocê também pode adicionar mapeamentos para navegar para cima/para baixo na pilha, alternar a janela de pontos de interrupção e mostrar a desmontagem, por exemplo:
nmap <LocalLeader> <F11> <Plug> VimspectorUpFrame
nmap <LocalLeader> <F12> <Plug> VimspectorDownFrame
nmap <LocalLeader> B <Plug> VimspectorBreakpoints
nmap <LocalLeader> D <Plug> VimspectorDisassembleEsta seção define instruções de uso detalhadas, organizadas por recurso. Para a maioria dos usuários, a seção de mapeamentos contém os comandos mais comuns e o uso padrão. Esta seção pode ser usada como referência para criar seus próprios mapeamentos ou comportamentos personalizados.
Todas as instruções abaixo pressupõem uma única sessão de depuração. Para obter detalhes sobre como depurar vários aplicativos independentes ao mesmo tempo, consulte [múltiplas sessões de depuração][#multiple-debugging-sessions].
.vimspector.json . Veja abaixo.:call vimspector#Launch() e selecione uma configuração.Iniciar uma nova sessão torna-a ativa [sessão de depuração][#multiple-debugging-sessions].
Se a configuração do adaptador de depuração usar pidProperty e você fizer uma solicitação attach , será solicitado que você insira um PID (ID do processo) ao qual anexar.
Para facilitar isso, o Vimspector fornece um pequeno utilitário para listar PIDs. É como um clone muito simples do ps , mas funciona em todas as plataformas suportadas. Consulte seu README para obter instruções sobre como configurá-lo.
Execute go build no diretório support/vimspector_process_list para configurá-lo.
Se o Vimspector conseguir encontrar este aplicativo, ele tentará listar todos os processos pertencentes ao usuário atual por padrão.
Alternativamente (de preferência), você pode usar uma forma especial de expansão de variável chamada ${PickProcess("binaryName")} . A versão desta chamada listará todos os processos do usuário atual que correspondem a este nome binário.
Por exemplo:
"Attach" : {
"adapter" : "CodeLLDB" ,
"configuration" : {
"request" : "attach" ,
"program" : "${workspaceRoot}/Jails" ,
"pid" : "${PickProcess("jails")}"
}
}Isso listará cada processo correspondente, seu processo pai, horário de início e diretório de trabalho. É algo assim:
PID PPID CWD START
52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24
Enter Process ID:
Você então insere o PID e pressiona <CR> .
Você pode até substituir o seletor de processos por sua própria função. Se você definir alguma função e definir g:vimspector_custom_process_picker_func como o nome dessa função. Serão passados quaisquer argumentos passados para a função de expansão PickProcess . Ele também será usado sempre que um pidProperty for especificado, portanto também não deve manipular argumentos (use ... como argumentos formais para a função, consulte :help ... ).
Por exemplo, para usar fzf junto com o vimspector_process_list fornecido:
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 para usar fzf com a saída 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 'Para iniciar uma configuração de depuração específica ou especificar variáveis de substituição para a inicialização, você pode usar:
:call vimspector#LaunchWithSettings( dict ) O argumento é um dict com as seguintes chaves:
configuration : (opcional) Nome da configuração de depuração a ser iniciada<anything else> : (opcional) Nome de uma variável a ser definida Isso permite alguma integração e automação. Por exemplo, se você tiver uma configuração chamada Run Test que contém uma variável de substituição chamada ${Test} você poderia escrever um mapeamento que finalmente executa:
vimspector#LaunchWithSettings ( #{ configuration: ' Run Test '
Test: ' Name of the test ' } ) Isso iniciaria a configuração Run Test com ${Test} definido como 'Name of the test' e o Vimspector não solicitaria ao usuário que inserisse ou confirmasse essas coisas.
Consulte nosso guia de integração YouCompleteMe para outro exemplo onde ele pode ser usado para especificar a porta para conectar o depurador java
Para iniciar com uma configuração ad-hoc, você pode usar:
call vimspector#LaunchWithConfigurations( dict ) O argumento é um dict que é a seção configurations de um arquivo .vimspector. Passe uma configuração e ela será selecionada como aquela a ser executada. Por exemplo:
let pid = <some_expression>
call vimspector#LaunchWithConfigurations ({
" attach " : {
" adapter " : " netcoredbg " ,
" configuration " : {
" request " : " attach " ,
" processId " : pid
}
}
} ) Isso iniciaria o depurador e se anexaria ao processo especificado sem a necessidade de ter um arquivo .vimspector local no disco. A variável ${workspaceRoot} apontará para a pasta pai do arquivo que está atualmente aberto no vim.
O Vimspector usa a seguinte lógica para escolher uma configuração para iniciar:
autoselect definida como false , use-a.default definido como true e sem autoselect definida como false , use-a.Consulte o guia de referência para obter detalhes.
vimspector#GetConfigurations() para obter uma lista de configurações para o tipo de arquivo do buffer atualPor exemplo, para obter uma matriz de configurações e correspondência difusa no resultado
: call matchfuzzy ( vimspector#GetConfigurations (), " test::case_1 " )Consulte a seção de mapeamentos para ver os mapeamentos padrão para trabalhar com pontos de interrupção. Esta seção descreve a API completa em funções vimscript.
Os pontos de interrupção estão associados à [sessão de depuração] atual [#multiple-debugging-sessions]. Ao alternar entre sessões, os sinais de ponto de interrupção da sessão anterior são removidos e os pontos de interrupção da sessão recém-ativada são exibidos. Embora possa ser útil ver pontos de interrupção para todas as sessões, isso pode ser muito confuso.
Use :VimspectorBreakpoints ou mapeie algo para <Plug>VimspectorBreakpoints para abrir a visualização dos pontos de interrupção. A partir daqui você pode listar, pular para excluir, adicionar e alternar pontos de interrupção.
Eu recomendo um mapeamento como este para alternar a janela de pontos de interrupção:
nmap <Leader> db <Plug> VimspectorBreakpointsOs seguintes mapeamentos se aplicam por padrão na janela de pontos de interrupção:
t , <F9> - alternar, ou seja, ativar/desativar ponto de interrupçãoT - alternar, ou seja, ativar/desativar TODOS os pontos de interrupçãodd , <Del> - exclui o ponto de interrupção atualcc , C - edita as opções atuais do ponto de interrupçãoi , a , o - adiciona um novo ponto de interrupção de linhaI , A , O - adicione um novo ponto de interrupção de função<Enter> ou clique duplo - salte para o ponto de interrupção da linhaUm WinBar também é fornecido (quando suportado). Isso adiciona funções como salvar/restaurar sessões, limpar todos os pontos de interrupção e redefinir as opções de pontos de interrupção de exceção.
A forma mais simples e comum de ponto de interrupção é um ponto de interrupção de linha. A execução é pausada quando a linha especificada é executada.
Para a maioria dos cenários de depuração, os usuários simplesmente pressionarão <F9> para criar um ponto de interrupção de linha na linha atual e <F5> para iniciar o aplicativo.
Alguns adaptadores de depuração suportam pontos de interrupção condicionais. Observe que o vimspector não informa se o depurador não suporta pontos de interrupção condicionais (ainda). Um ponto de interrupção condicional é um ponto de interrupção que só é acionado se alguma expressão for avaliada como verdadeira ou se alguma outra restrição for atendida.
Algumas dessas funções acima aceitam um único argumento opcional que é um dicionário de opções. O dicionário pode ter as seguintes chaves:
condition : uma expressão opcional avaliada para determinar se o ponto de interrupção deve ser acionado. Não suportado por todos os adaptadores de depuração. Por exemplo, para quebrar quando abc for 10 , insira algo como abc == 10 , dependendo do idioma.hitCondition : uma expressão opcional avaliada para determinar o número de vezes que o ponto de interrupção deve ser ignorado. Não deveria (provavelmente?) ser usado em combinação com condition . Não suportado por todos os adaptadores de depuração. Por exemplo, para quebrar na terceira vez que atingir esta linha, insira 3 .logMessage : Uma string opcional para tornar este ponto de interrupção um "logpoint". Quando acionada, esta mensagem é impressa no console em vez de interromper a execução. Você pode incorporar expressões entre colchetes {like this} , por exemplo #{ logMessage: "Iteration {i} or {num_entries / 2}" }Em cada caso, as expressões são avaliadas pelo depurador, portanto devem estar em qualquer dialeto que o depurador entenda ao avaliar as expressões.
Ao utilizar o mapeamento <leader><F9> , o usuário é solicitado a inserir essas expressões em uma linha de comando (com histórico).
Os pontos de interrupção de exceção normalmente são acionados quando uma exceção é lançada ou ocorre outra condição de erro. Dependendo do depurador, ao iniciar a depuração, poderão ser feitas algumas perguntas sobre como lidar com exceções. Esses são "pontos de interrupção de exceção" e o vimspector lembra suas escolhas enquanto o Vim ainda está em execução.
Normalmente você pode aceitar os padrões (continue pressionando <CR> !), já que a maioria dos padrões do adaptador de depuração são sensatos, mas se você quiser interromper, diga uncaught exception e responda Y para isso (por exemplo).
Você pode configurar suas escolhas em .vimspector.json . Consulte o guia de configuração para obter detalhes sobre isso.
NOTA: Anteriormente, o ToggleBreakpoint alternava entre 3 estados: ativado, desativado, excluído. Muitos usuários descobriram que o estado ‘desativado’ raramente era útil, então o comportamento foi alterado. ToggleBreakpoint sempre cria ou exclui um ponto de interrupção. Se você deseja 'desabilitar' os pontos de interrupção, use a janela de pontos de interrupção e 'alternar' ( t ) a partir daí.
vimspector#ToggleBreakpoint( { options dict } ) para definir/excluir um ponto de interrupção de linha. O argumento é opcional (veja abaixo).vimspector#AddFunctionBreakpoint( '<name>', { options dict} ) para adicionar um ponto de interrupção de função. O segundo argumento é opcional (veja abaixo).vimspector#SetLineBreakpoint( file_name, line_num, { options dict } ) para definir um ponto de interrupção em um arquivo/linha específico. O último argumento é opcional (veja abaixo)vimspector#ClearLineBreakpoint( file_name, line_num ) para remover um ponto de interrupção em um arquivo/linha específicovimspector#ClearBreakpoints() para limpar todos os pontos de interrupçãovimspector#ResetExceptionBreakpoints() para limpar a configuração dos pontos de interrupção de exceção e responder novamente às várias questões como "Break on C++ Throw":VimspectorMkSession e :VimspectorLoadSession para salvar e restaurar pontos de interrupçãocall vimspector#ListBreakpoints() - alterna janela de pontos de interrupçãocall vimspector#BreakpointsAsQuickFix() - retorne o conjunto atual de pontos de interrupção no formato vim quickfixExemplos:
call vimspector#ToggleBreakpoint() - alterna o ponto de interrupção na linha atualcall vimspector#SetLineBreakpoint( 'some_file.py', 10 ) - defina um ponto de interrupção em some_filepy:10call vimspector#AddFunctionBreakpoint( 'main' ) - adicione um ponto de interrupção de função na função maincall vimspector#ToggleBreakpoint( { 'condition': 'i > 5' } ) - adicione um ponto de interrupção na linha atual que é acionado somente quando i > 5 for truecall vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i > 5' } ) - adicione um ponto de interrupção em some_file.py:10 que é acionado somente quando i > 5 for truecall vimspector#ClearLineBreakpoint( 'some_file.py', 10 ) - exclua o ponto de interrupção em some_file.py:10call vimspector#ClearBreakpoints() - limpe todos os pontos de interrupçãoVimspectorMkSession - crie .vimspector.sessionVimspectorLoadSession - leia .vimspector.sessionVimspectorMkSession my_session_file - crie my_session_fileVimspectorLoadSession my_session_file - leia my_session_fileNOTA : Recurso experimental, que pode mudar significativamente no futuro com base no feedback do usuário.
Os pontos de interrupção de instrução podem ser adicionados na janela de desmontagem da mesma maneira que você adiciona pontos de interrupção de linha na janela de código. Os mesmos mapeamentos e funções funcionam para adicioná-los e alterná-los. Quando suportado pelo adaptador de depuração, você pode até criar logpoints e pontos de interrupção condicionais dessa maneira.
Atualmente, os pontos de interrupção das instruções são modelados internamente como pontos de interrupção de linha contra o buffer que contém a desmontagem, mas isso pode mudar no futuro; portanto, não confie nisso.
Os pontos de interrupção da instrução também são visíveis e podem ser excluídos/desabilitados na janela Pontos de interrupção.
Atualmente, os pontos de interrupção das instruções são limpos automaticamente quando a sessão de depuração terminar. O motivo disso é que os endereços não podem ser válidos para qualquer outra sessão de depuração. No entanto, isso também pode mudar no futuro.
Use vimspector#ClearBreakpoints() para limpar todos os pontos de interrupção, incluindo a memória das opções de ponto de interrupção da exceção.
Use vimspector#RunToCursor ou <leader><F8> : Isso cria um ponto de interrupção temporário na linha atual e continua a execução, limpando o ponto de interrupção quando for atingido.
Use vimspector#GoToCurrentLine() ou algum mapeamento para <Plug>VimspectorGoToCurrentLine para saltar a execução atual na linha que seu cursor está ativado.
Onde suportado, isso pode ser útil para executar seções de código ou pular completamente sobre elas.
Se houver vários "alvos" possíveis na linha atual, você é solicitado a escolher um.
O VimsPetor pode salvar e restaurar pontos de interrupção (e algumas outras coisas) em um arquivo de sessão. Os seguintes comandos existem para isso:
VimspectorMkSession [file/dir name] - Salve o conjunto atual de pontos de interrupção da linha, pontos de log, pontos de interrupção condicional, pontos de interrupção da função e filtros de ponto de interrupção de exceção no arquivo de sessão fornecidos ou ao arquivo padrão no diretório fornecido.VimspectorLoadSession [file/dir name] - Leia pontos de interrupção do arquivo de sessão fornecido ou do arquivo padrão no diretório fornecido e substitua os pontos de interrupção atualmente definidos. Antes do carregamento, todos os pontos de interrupção atuais são limpos (como se vimspector#ClearLineBreakpoints() fosse chamado). Nos dois casos, o argumento do nome do arquivo/direção é opcional. Por padrão, o arquivo é nomeado .vimspector.session , mas isso pode ser alterado globalmente, definindo g:vimspector_session_file_name para outra coisa, ou especificando manualmente um caminho ao chamar o comando. Se você fornecer um diretório, o nome do arquivo de sessão padrão ou configurado será lido ou gravado para esse diretório. Othewise, o arquivo é lido com base no buffer atualmente aberto ou escrito no diretório de trabalho atual.
Os usuários avançados podem querer automatizar o processo de carregamento e salvamento, por exemplo, adicionando autocomandos VimEnter e VimLeave . É recomendável nesse caso usar silent! Para evitar erros irritantes se o arquivo não puder ser lido ou escrito.
A forma mais simples de automação é carregar a sessão do vimspect sempre que você inicia o VIM com um arquivo de sessão. Isso é tão simples quanto fazer isso:
$ echo silent VimspectorLoadSession > Sessionx.vim
Consulte :help mksession para obter detalhes do arquivo *x.vim . Você também pode fazer algo assim usando SessionLoadPost :
autocmd SessionLoadPost * silent ! VimspectorLoadSessionvimspector#StepInto() etc. também existem vimspector#StepSOver() e vimspector#StepIOver() etc. Variantes para granularidade de instrução e instrução, respectivamente. <CR> ou clique duas vezes com o mouse esquerdo para expandir/colapso (+, -).<C-CR> (Control + <CR> ) ou <leader><CR> (se modifyOtherKeys não funcionar para você) Escopos e variáveis são representados pelo buffer vimspector.Variables .
Se você preferir uma exibição mais detalhada para variáveis e relógios, pode let g:vimspector_variables_display_mode = 'full' . Por padrão, apenas o nome e o valor são exibidos, com outros dados disponíveis em pairar o mouse ou acionar <Plug>VimspectorBalloonEval na linha que contém o valor na janela Variáveis (ou relógios).
Todas as regras para Variables and scopes se aplicam mais o seguinte:
a + b ) e obtenha seu resultado.nmap ) e o modo visual ( xmap ) mapeando para <Plug>VimspectorBalloonEval para acionar manualmente o pop -up.<C-CR> (Control + <CR> ) ou <leader><CR> (se modifyOtherKeys não funcionar para você)j , k ) para escolher a seleção atual; <Esc> (ou deixe a janela da dica de ferramenta) para fechar a dica de ferramenta. Você pode desativar o pop -up de pau automático por configurações g:vimspector_enable_auto_hover=0 antes de iniciar a sessão de depuração. Em seguida, você pode mapear algo para <Plug>VimspectorBalloonEval e acioná -lo manualmente.
A janela do relógio é usada para inspecionar variáveis e expressões. Expressões são avaliadas na estrutura de pilha selecionada que está "focada"
A janela dos relógios é um buffer rápido, onde está disponível. Digite o modo de inserção para adicionar uma nova expressão de relógio.
<CR> .:VimspectorWatch <expression> . A conclusão da TAB para expressão está disponível em alguns adaptadores de depuração.<CR> ou clique duas vezes com o mouse esquerdo.<C-CR> (Control + <CR> ) ou <leader><CR> (se modifyOtherKeys não funcionar para você)<DEL> . Os relógios são representados pelo buffer vimspector.Watches .
Se você preferir uma exibição mais detalhada para variáveis e relógios, pode let g:vimspector_variables_display_mode = 'full' . Por padrão, apenas o nome e o valor são exibidos, com outros dados disponíveis em pairar o mouse ou acionar <Plug>VimspectorBalloonEval na linha que contém o valor na janela Variáveis (ou relógios).
Você pode desativar o pop -up de pau automático por configurações g:vimspector_enable_auto_hover=0 antes de iniciar a sessão de depuração. Em seguida, você pode mapear algo para <Plug>VimspectorBalloonEval e acioná -lo manualmente.
O buffer de prompt de relógio tem seu omnifunc definido como uma função que calculará a conclusão para a expressão atual. Isso é utilizado trivialmente com <Ctrl-x><Ctrl-o> (consulte :help ins-completion ) ou integrado ao seu sistema de conclusão favorito. O FileType no buffer está definido como VimspectorPrompt .
Para YouCompleteme, a seguinte configuração funciona bem:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}:VimspectorDisassemble vimspector#ShowDisassembly() <Plug>VimspectorDisassembleAlguns adaptadores de depuração (poucos!) Apoiam a desmontagem. A maneira como isso funciona no DAP é um pouco estranho, mas, na prática, o vimspetor pedirá para desmontar uma série de instruções em torno do PC do quadro da pilha atual. Isso é mostrado em uma janela com um winbar semelhante à janela de código, mas com a granularidade de ensino. Há um sinal para a instrução atual e os padrões de sintaxe no alto de altura do "ASM", que funcionam principalmente para x86 e braço.
Como mencionado acima, quando sua janela atual é o Windows de desmontagem e você usa os comandos "etapas" padrão (por exemplo, <F10> ), o passo é automaticamente agendado para a instrução, e não por instrução.
Cada vez que o processo para, o Vimspect solicita cerca de duas janelas cheias de instruções em torno do PC atual. Para ver mais, você pode rolar a janela. O VimsPetor page em uma tela extra de instruções quando a janela rolar para a parte superior ou próxima da parte inferior. Isso não é perfeito. Às vezes, você precisa rolar um pouco mais para fazê-lo na página (por exemplo, Ctrl-e Ctrl-Y na parte superior). Isso não é ideal e pode ser melhorado no futuro.
Você pode controlar a altura íntima da janela de desmontagem com let g:vimspector_disassembly_height = 10 (ou número Whatver de linhas).
O FileType (e a sintaxe) dos buffers na janela de desmontagem é vimspector-disassembly . Você pode usar FileType AutoCommands para personalizar coisas como o destaque da sintaxe.
Nota : esse recurso é experimental e pode mudar de qualquer maneira com base no feedback do usuário.
Alguns adaptadores de depuração fornecem uma maneira de despejar a memória do processo associada a variáveis. Isso pode ser feito a partir das variáveis e observa as janelas com:
<leader>m Mapping (por padrão, pode ser personalizado)vimspector#ReadMemory() Ao fazer isso, você é solicitado a inserir vários bytes para ler (a partir do local associado à linha atual do cursor) e a um deslocamento desse local. Um novo buffer é exibido na janela de código que contém um despejo de memória em hexadecimal e ascii, semelhante à saída de xxd .
Nota : esse recurso é experimental e pode mudar de qualquer maneira com base no feedback do usuário.
A janela de rastreamento da pilha mostra o estado de cada tópico do programa. Os threads que são parados podem ser expandidos para mostrar o traço da pilha desse thread.
Muitas vezes, mas nem sempre, todos os tópicos são interrompidos quando um ponto de interrupção é atingido. O status de um thread é mostrado entre parênteses após o nome do thread. Quando apoiados pelo depurador subjacente, os threads podem ser pausados e continuados individualmente a partir da janela de rastreamento da pilha.
Um encadeamento específico, destacado com o grupo de destaque CursorLine é o thread "focado". Este é o thread que recebe comandos como "passo", "etapa", "continue" e "pausa" na janela de código. O encadeamento focado pode ser alterado manualmente para "alternar" esse encadeamento.
<CR> ou clique duas vezes com o mouse esquerdo para expandir/recolher um rastreamento de pilha de thread ou usar o botão WinBar.<CR> ou clique duas vezes com o mouse esquerdo em uma estrutura de pilha para pular.vimspector#PauseContinueThread() para pausar ou continuar individualmente o thread selecionado.<leader><CR> ou vimspector#SetCurrentThread() para definir o thread "focado" para o atualmente selecionado. Se a linha selecionada for um quadro de pilha, defina o encadeamento focado no encadeamento desse quadro e pule para esse quadro na janela de código. O rastreamento da pilha é representado pelo buffer vimspector.StackTrace .
Se houver sessões de depuração infantil, como onde o debugue lança processos infantis e o adaptador de depuração suporta depuração de várias sessões, os threads de cada sessão serão mostrados separadamente. A sessão atualmente ativa é a que é destacada como o quadro de thread/pilha atualmente ativo. Para alternar o controle para uma sessão diferente, concentre um tópico nessa sessão.
Nota: refere-se a sessões criadas como filhos de uma sessão existente e não deve ser confundido com [sessões de depuração (múltiplas (pais)] [#sessões múltiplas de debugação].
:VimspectorShowOutput <category> . Use a conclusão da linha de comando para ver as categorias. Se a janela de saída estiver fechada, uma nova poderá ser aberta com :VimspectorShowOutput <category> (use a conclusão da guia - wildmenu para ver as opções).
A janela do console é um buffer rápido, onde está disponível, e pode ser usado como uma CLI interativa para o adaptador de depuração. O suporte a isso varia entre os adaptadores.
:VimspectorEval <expression> . A conclusão está disponível com alguns adaptadores de depuração.<CR>Nota: Consulte também relógios acima.
Se a janela de saída estiver fechada, uma nova poderá ser aberta com :VimspectorShowOutput Console .
O buffer de prompt do console tem seu omnifunc definido como uma função que calculará a conclusão para o comando/expressão atual. Isso é utilizado trivialmente com <Ctrl-x><Ctrl-o> (consulte :help ins-completion ) ou integrado ao seu sistema de conclusão favorito. O FileType no buffer está definido como VimspectorPrompt .
Para YouCompleteme, a seguinte configuração funciona bem:
let g: ycm_semantic_triggers = {
' VimspectorPrompt ' : [ ' . ' , ' -> ' , ' : ' , ' < ' ]
}O arquivo de log do VimsSpector contém um traço completo da comunicação entre o Vimspect e o adaptador de depuração. Esta é a principal fonte de informações de diagnóstico quando algo dá errado, que não é um traceback Vim.
Se você deseja apenas ver o arquivo de log do vimspect, use :VimspectorToggleLog , que o encaixará em uma pequena janela (não funciona no Windows).
Você pode ver algumas informações de depuração com :VimspectorDebugInfo
Para fechar o depurador, use:
Reset o botão WinBar:VimspectorReset Quando o Winbar não estiver disponível.call vimspector#Reset()Se o Debuggee ainda estiver em execução ao parar ou redefinir, alguns adaptadores de depuração permitem especificar o que deve acontecer com ele ao terminar a depuração. Normalmente, o comportamento padrão é sensato, e é isso que acontece na maioria das vezes. Estes são os padrões de acordo com o DAP:
Alguns adaptadores de depuração permitem que você escolha o que fazer ao desconectar. Se você deseja controlar esse comportamento, use :VimspectorReset ou ligue para vimspector#Reset( { 'interactive': v:true } ) . Se o adaptador de depuração oferecer uma opção para encerrar ou não o depuração, você será solicitado a escolher. O mesmo se aplica ao vimspector#Stop() que pode assumir um argumento: vimspector#Stop( { 'interactive': v:true } ) .
Nota : Esse recurso é experimental e qualquer parte pode mudar em resposta ao feedback do usuário.
O VimsPetor suporta iniciar um número arbitrário de sessões de depuração. Cada sessão está associada a uma guia individual da interface do usuário. Normalmente, você apenas depura um único aplicativo e, portanto, não precisa pensar sobre isso, mas esse recurso avançado pode ser útil se você precisar depurar simultaneamente vários aplicativos independentes ou várias instâncias independentes do seu aplicativo.
A qualquer momento, há uma única sessão de raiz "ativa". Os pontos de interrupção estão associados à sessão atual e todos os comandos de interface do usuário e API são aplicados à sessão atualmente ativa.
Ao alternar entre as sessões raiz, os sinais de breakpont para a sessão anterior são removidos e os pontos de interrupção da sessão recém -ativada são exibidos. Embora possa ser útil ver pontos de interrupção para todas as sessões, isso pode ser muito confuso.
Um fluxo de trabalho típico pode ser:
:edit server.cc então <F5> ). Isso inicia uma sessão de depuração com o nome da configuração selecionada. Você pode renomeá -lo :VimspectorRenameSession server .:tabedit client.cc )client :: :VimspectorNewSession client ( client agora é a sessão ativa).client e comece a depurar com <F5> . Agora você tem 2 guias de vimspect. Intuitivamente, a Wwitching para uma guia específica tornará sua sessão ativa. Você também pode alternar manualmente a sessão ativa com :VimspectorSwitchToSession <name> .
Então, em resumo, você tem as seguintes instalações:
VimspectorNewSession <name> Isso cria uma nova sessão e a torna ativa. O nome opcional é usado no lugar do gerado ao iniciar um lançamento.VimspectorSwitchToSession <tab complete> .VimspectorRenameSession <new name>VimspectorDestroySession <name> . Você não pode destruir uma sessão de corrida/ativa.vimspector#GetSessionName() útil para colocar uma linha de status. Há também vimspector#GetSessionID() para técnicos. Aqui está um exemplo de como você pode exibir o nome da sessão atual no statusline (consulte :help statusline ou a documentação para o seu plugin de linha de status sofisticado).
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 ()} % ) Para uma introdução à configuração do .vimspector.json , dê uma olhada na seção de início do site do Vimspect.
Para uma explicação completa, incluindo como usar variáveis, substituições e como especificar pontos de interrupção de exceção, consulte os documentos.
O arquivo de configuração JSON permite comentários no estilo C:
// comment to end of line .../* inline comment ... */Atualmente testado com os seguintes adaptadores de depuração.
Exemplo .vimspector.json (trabalha com vscode-cpptools e lldb-vscode . Para lldb-vscode substitua o nome do adaptador pelo 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> "
}
}
// ...
}
} Nota para usuários do Windows: você precisa instalar gdb.exe . Eu recomendo usar scoop install gdb . O VimsPetor não pode usar o depurador do Visual Studio devido ao licenciamento.
{
"configurations" : {
"Launch" : {
"adapter" : " vscode-cpptools " ,
"filetypes" : [ " cpp " , " c " , " objc " , " rust " ], // optional
"configuration" : {
"request" : " launch " ,
"program" : " <path to binary> " ,
"stopAtEntry" : true
}
}
}
}Dependendo do back -end, você precisa ativar a impressão bonita de tipos complexos manualmente.
LLDB: a impressão bonita é ativada por padrão
GDB: Para ativar as impressoras bonitas do GDB, considere o trecho abaixo. Não basta ter set print pretty on no seu .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
}
]
}
}
}
} A documentação do CPPTools descreve como anexar o CPPTools ao gdbServer usando miDebuggerAddress . Observe que, ao fazer isso, você deve usar a "request": "attach" .
Se você estiver se sentindo chique, consulte o guia de referência para obter um exemplo de que o Vimspecttor se inicie e anexe remotamente.
O CodellDB é superior ao VSCODE-CPPTOOLS de várias maneiras, pelo menos no MacOS.
Veja ferrugem.
Uma alternativa é usar lldb-vscode , que vem com LLVM. Veja como:
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 "
}
}
} A ferrugem é suportada com qualquer depurador baseado em GDB/LLDB. Portanto, funciona bem com vscode-cpptools e lldb-vscode acima. No entanto, o suporte à ferrugem é o melhor no 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" - isso é inválido. Em vez disso, use "request": "launch", "custom": true . Porque razõescargo é feita na loucura do vscode javascript, por isso não é suportado."request": custom ; Veja o ponto sobre o lançamento "personalizado" acimastep-into as funções da biblioteca padrão) pode ser feito adicionando "sourceMap": { "from_path" : "to_path" } . "from_path" pode ser encontrado na janela de desmontagem subindo no rastreamento da pilha; "to_path" é apenas o caminho da biblioteca padrão instalado localmente para a cadeia de ferramentas atual. Jai Debugging funciona bem com qualquer um dos outros depuradores nativos. Eu recomendo Codelldb, mas o CPPTools também funciona.
Exemplo:
{
"$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: Depurador
Instale com install_gadget.py --enable-python ou :VimspectorInstall debugpy , idealmente requer um compilador de trabalho e os cabeçalhos de desenvolvimento do Python/LIBs para construir uma extensão C Python para desempenho.
NOTA : Debugpy não suporta mais o Python 2. Para continuar a depurar aplicativos Python 2, use o adaptador debugpy-python2 após a instalação do gadget debugpy-python2 .
Opções completas: 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> "
}
}
...
}
}Para usar a depuração remota com a depuração, você deve conectar o VimsPetor diretamente ao aplicativo que está sendo depurado. Isso é fácil, mas é um pouco diferente de como normalmente configuramos as coisas. Especificamente, você precisa:
--listen . Consulte a documentação depra para detalhes.{
"configurations" : {
"Python Attach" : {
"adapter" : " multi-session " ,
"filetypes" : [ " python " ], // optional
"configuration" : {
"request" : " attach " ,
"pathMappings" : [
// mappings here (optional)
]
}
}
}
} Veja detalhes da configuração de lançamento para explicar coisas como pathMappings .
A documentação adicional, incluindo como fazer isso quando a máquina remota só pode ser contatada via SSH é fornecido pela Depy.
Se você estiver se sentindo chique, consulte o guia de referência para obter um exemplo de que o Vimspecttor se inicie e anexe remotamente.
Para continuar a depurar os aplicativos Python 2, verifique se você instala o gadget debugpy-python2 (por exemplo --force-enable-python2 ou :VimspectorInstall debugpy-python2 ) e alterar sua configuração para usar:
{
"configurations" : {
"Python Attach" : {
"adapter" : " debugpy-python2 " ,
// ...
}
}
}
Para Examk
Veja o meu garfo do TCLProdeBug para obter instruções.
Instale com 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" : {}
}
}
}
}Requer:
install_gadget.py --enable-go ou :VimspectorInstall delvego 1.16 ou mais tarde (YMMV nas versões anteriores)Isso usa o suporte DAP incorporado ao depurador 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 "
}
}
}
}Use variáveis para configurar o seguinte:
dlvFlags : (string) argumentos adicionais da linha de comando para passar para mergulharO depurador (DELVE) é lançado em uma janela de terminal para que você possa ver sua saída e passar a entrada para o Debuggee.
Consulte os documentos do VSCODE-GO para obter opções completas de lançamento. Sim, parece que esse é o único lugar em que eles estão documentados (aparentemente, eles não estão documentados pelo Defline).
Os documentos do Vscode-Go também têm informações úteis para solucionar problemas
Requer:
install_gadget.py --enable-go ou :VimspectorInstall vscode-gogo get -u github.com/go-delve/delve/cmd/dlvdlvToolPathNOTA: O Vimspector usa o adaptador de depuração do VSCODE-GO "Legacy", em vez do suporte DAP "embutido" no Delve. Você pode rastrear #186 para isso.
{
"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" ]
}
}
}
}Veja os documentos do VSCODE-GO para obter informações sobre solução de problemas
Isso usa o php-debug, consulte https://marketplace.visualstudio.com/items?itemname=felixfbecker.php-debug
Requer:
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 Substitua localhost pelo IP da sua estação de trabalho.
alternativa preguiçosa
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
}
}
}
} Anexar XDEBUG_SESSION_START=xdebug na sua sequência de consulta
curl "http://localhost?XDEBUG_SESSION_START=xdebug"
ou use a extensão Helper Xdebug mencionada anteriormente (que define um cookie XDEBUG_SESSION )
export XDEBUG_CONFIG= " idekey=xdebug "
php < path to script > Isso usa o VSCODE-JS-DEBUG, o depurador que também é usado no VSCode. Para configurações adicionais, verifique a documentação aqui.
Para instalar o vscode-js-debug, execute VimspectorInstall vscode-js-debug a partir do vim ou execute o script de instalação install_gadget.py --force-enable-node . Existem vários exemplos que você pode conferir. Encontre -os em support/test/node/simple , support/test/node/multiprocess e support/test/node/typescript . Uma configuração típica para a depuração de depuração se parece com o seguinte:
{
"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 suporta vários "tipos" diferentes e pode fazer algumas coisas que podem ou não funcionar. Infelizmente, o campo type não está documentado, mas os valores válidos são definidos aqui no enum debugtype.
O VimsPetor foi testado apenas com o tipo pwa-node .
Observe também que, por algum motivo, este adaptador de depuração sempre nos obriga a iniciar várias sessões de depuração. Para um usuário, isso não deve mudar nada (além de talvez um rastreamento de pilha um pouco confuso). Mas isso torna as coisas mais complicadas e, portanto, podem haver bugs sutis.
Isso usa o depurador Chrome/Firefox (eles são muito semelhantes), consulte https://marketplace.visualstudio.com/items?itemname=msjsdiag.debugger-for-chrome e https://marketplace.visualstudio.com/items? = firefox-devtools.vscode-firefox-debug, respectivamente.
Ele permite que você depure os scripts que rodam dentro do Chrome de dentro do 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
}
}
}
}O Vimspector funciona bem com o Java Debug Server, que é executado como um plug -in JDT.LS (Java Language Server), em vez de um adaptador de depuração independente.
O Vimspecttor não está no negócio de executar servidores de idiomas, apenas adaptadores de depuração, portanto, isso significa que você precisa de um plug -in de editor de protocolo de Language Server compatível para usar o Java. Eu recomendo o YouCompleteme, que tem suporte total ao JDT.LS, e o mais importante é uma maneira trivial de carregar o adaptador de depuração e usá -lo com o vimspect.
Ao usar o servidor Java Debug, o VimSpect suporta o código quente, substitua o recurso personalizado. Por padrão, quando os arquivos da classe subjacente alteram, o Vimspect pergunta ao usuário se eles desejam recarregar essas classes em tempo de execução.
Este comportamento pode ser personalizado:
let g:vimspector_java_hotcodereplace_mode = 'ask' - o padrão, peça ao usuário cada recarregar.let g:vimspector_java_hotcodereplace_mode = 'always' - Não pergunte, sempre recarreguelet g:vimspector_java_hotcodereplace_mode = 'never' - Não pergunte, nunca recarregueinstall_gadget.py --force-enable-java <other options...> ou :VimspectorInstall java-debug-adaptervscode-java , por exemplo: {
"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> , não qualquer adaptador específico. por exemplo, em .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> para iniciar o servidor depurador e iniciar o vimspect, por exemplo, em ~/.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>
Você pode usar <Leader><F5> para começar a depurar em vez de apenas <F5> .
Se você vê "Não é possível obter a porta DAP - JDT.LS é inicializada?", Tente executar :YcmCompleter ExecuteCommand vscode.java.startDebugSession e observe a saída. Se você vir um erro como ResponseFailedException: Request failed: -32601: No delegateCommandHandler for vscode.java.startDebugSession , verifique se:
g:ycm_java_jdtls_extension_path está definido em .vimrc ou antes da partida do YCMPara os argumentos de lançamento, consulte o documento do VSCode.
Veja esta questão para obter mais antecedentes.
O Lua é suportado através do local-lua-debugger-vscode. Este depurador usa o Stdio para se comunicar com o processo de execução, portanto, as chamadas para io.read causarão problemas.
./install_gadget.py --enable-lua ou :VimspectorInstall local-lua-debugger-vscodesupport/test/lua/simple e 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} " ]
}
}
}
}Há suporte muito limitado para a personalização da interface do usuário.
O VimSector usa os seguintes sinais internamente. Se eles forem definidos antes que o VimSector os use, eles não serão substituídos. Portanto, para personalizar os sinais, defina -os no seu vimrc .
| Sinal | Descrição | Prioridade |
|---|---|---|
vimspectorBP | Ponto de interrupção da linha | 9 |
vimspectorBPCond | Ponto de interrupção da linha condicional | 9 |
vimspectorBPLog | LogPoint | 9 |
vimspectorBPDisabled | Ponto de interrupção desativado | 9 |
vimspectorPC | Contador de programas (ou seja, linha atual) | 200 |
vimspectorPCBP | Contador de programas e ponto de interrupção | 200 |
vimspectorNonActivePC | Contador de programas para tópico não focado | 9 |
vimspectorCurrentThread | Tópico focado na visualização de rastreamento de pilha | 200 |
vimspectorCurrentFrame | Quadro de pilha atual na visualização de rastreamento da pilha | 200 |
Os símbolos padrão são o equivalente a algo como o seguinte:
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 Se os sinais não exibirem corretamente, sua fonte provavelmente não contém esses glifos. Você pode alterá -los facilmente definindo o sinal no seu VIMRC. Por exemplo, você pode colocar isso no seu vimrc para usar alguns símbolos 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 Muitos plugins diferentes fornecem sinais para vários propósitos. Os exemplos incluem sinais de diagnóstico para erros de código, etc. O VIM fornece apenas uma única prioridade para determinar qual sinal deve ser exibido quando vários sinais são colocados em uma única linha. Se você está descobrindo que outros sinais estão interferindo no VimsSpector's (ou vice-versa), pode personalizar a prioridade usada pelo Vimspector definindo o seguinte dicionário:
let g: vimspector_sign_priority = {
' <sign-name> ' : <priority> ,
}Por exemplo:
let g: vimspector_sign_priority = {
' vimspectorBP ' : 3 ,
' vimspectorBPCond ' : 3 ,
' vimspectorBPLog ' : 3 ,
' vimspectorBPDisabled ' : 3 ,
' vimspectorNonActivePC ' : 3 ,
' vimspectorPC ' : 999 ,
' vimspectorPCBP ' : 999 ,
}Todas as chaves são opcionais. Se um sinal não for personalizado, a prioridade padrão usada (como mostrado acima).
Veja :help sign-priority . A prioridade padrão é 10, os números maiores substituem os menores.
NOTA : O sinal padrão vimspectorNonActivePC não adiciona nenhum texto à coluna Sign, ele simplesmente adiciona um destaque da linha para que você possa ver as linhas em que outros threads ou processos são interrompidos no momento. Como resultado, esse sinal normalmente deve se fundir com qualquer sinal que adicione um símbolo (como um sinal de ponto de interrupção). O VIM só mesclará as propriedades dos sinais com a mesma prioridade; portanto, se alterar as prioridades padrão, é recomendável que:
vimspectorBP , vimspectorBPCond , etc.) têm a mesma prioridade.vimspectorNonActivePC nessa mesma prioridadevimspectorPC , vimspectorPCBP , etc.) tem uma prioridade mais alta. NOTA: Este ponto de personalização é atualmente inseguro e pode mudar a qualquer momento.
Às vezes, o adaptador de depuração fornece dicas sobre como a interface do usuário deve exibir certas coisas. Isso inclui quadros de pilha, variáveis etc.
O VimsPetor fornece uma maneira simples de personalizar como eles são exibidos, definindo valores no dicionário g:vimsepctor_presentation_hint_hl .
As teclas a seguir são suportadas com o grupo de destaque padrão mencionado.
| Grupo | Chave | Uso | Padrão |
|---|---|---|---|
| todos | normal | qualquer coisa não coberta abaixo | Normal |
| Rastreamento da pilha | emphasize | Enfatize fontes no rastreamento da pilha | Title |
| Rastreamento da pilha | deemphasize | Considere as fontes no rastreamento da pilha | Conceal |
| Rastreamento da pilha | label | quadros de pilha que são "rótulos", não representando quadros reais | NonText |
| Rastreamento da pilha | subtle | quadros de pilha que são internos ou não interessantes | Conceal |
| Escopos | arguments | Função Argumentos Escopo | Title |
| Escopos | locals | Variáveis locais Escopo | Title |
| Escopos | registers | Registra escopo | Title |
| Variáveis | property | Função Argumentos Escopo | Identifier |
| Variáveis | method | Variáveis locais Escopo | Function |
| Variáveis | class | Registra escopo | Type |
| Variáveis | data | Registra escopo | String |
Além disso, qualquer valor fornecido na VariablePresentationHint DAP pode ser definido que será usado se for fornecido pelo adaptador de depuração.
Um exemplo bobo; Os padrões provavelmente devem estar bem para a maioria dos scehemes coloridos:
let g: vimspector_presentation_hint_hl = {
' normal ' : ' Identifier ' ,
' label ' : ' Title ' ,
}Observação : esta API de personalização é instável , o que significa que pode mudar a qualquer momento. Vou me esforçar para reduzir o impacto disso e anunciar mudanças no Gitter.
As seguintes opções controlam os tamanhos padrão das janelas da interface do usuário (todas elas são números)
g:vimspector_sidebar_width (padrão: 50 colunas): a largura nas colunas das janelas do utilitário esquerdo (variáveis, relógios, rastreamento de pilha)g:vimspector_bottombar_height (padrão 10 linhas): a altura nas linhas da janela de saída abaixo da janela de código.Exemplo:
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.
Exemplo:
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? Você não precisa. 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 " : " "
}
}
} }
