puremourning / vimspector Goto Github PK

vimspector - A multi-language debugging system for Vim

Home Page: http://puremourning.github.io/vimspector-web

License: Apache License 2.0

Python 42.41% Shell 2.72% C++ 0.08% Java 0.19% Dockerfile 0.66% C# 0.10% Go 0.52% JavaScript 0.20% HTML 0.17% Rust 0.02% Tcl 0.07% Ruby 0.03% Lua 0.14% Kotlin 0.01% Makefile 0.10% PHP 0.01% Vim Script 52.56% C 0.01%

vim debugging debugger debug-adapter-protocol cpp python tcl java

vimspector's Introduction

vimspector - A multi language graphical debugger for Vim

For a tutorial and usage overview, take a look at the Vimspector website.

For detailed explanation of the .vimspector.json format, see the reference guide.

Features and Usage
Installation
About
- Background
What Vimspector is not
Mappings
- Visual Studio / VSCode
- Human Mode
Usage and API
Multiple debugging sessions
Debug profile configuration
Customisation
FAQ

Features and Usage

The plugin is a capable Vim graphical debugger for multiple languages. It's mostly tested for C++, Python and TCL, but in theory supports any language that Visual Studio Code supports (but see caveats).

The Vimspector website has an overview of the UI, along with basic instructions for configuration and setup.

But for now, here's a (rather old) screenshot of Vimspector debugging Vim:

And a couple of brief demos:

Supported debugging features

flexible configuration syntax that can be checked in to source control
breakpoints (function, line and exception breakpoints)
conditional breakpoints (function, line)
step in/out/over/up, stop, restart
run to cursor
go to line (reset program counter to line)
launch and attach, including PID picker
remote launch, remote attach
locals and globals display
watch expressions with autocompletion
variable inspection tooltip on hover
disassembly view and step-by-instruction
set variable value in locals, watch and hover windows
call stack display and navigation
hierarchical variable value display popup (see <Plug>VimspectorBalloonEval)
interactive debug console with autocompletion
launch debuggee within Vim's embedded terminal
logging/stdout display
simple stable API for custom tooling (e.g. integrate with language server)
view hex dump of process memory
multiple independent debugging sessions (debug different apps in tabs)
multi-process (multi-session) debugging

Supported languages

The following table lists the languages that are "built-in" (along with their runtime dependencies). They are categorised by their level of support:

Tested : Fully supported, Vimspector regression tests cover them
Supported : Fully supported, frequently used and manually tested
Experimental: Working, but not frequently used and rarely tested
Legacy: No longer supported, please migrate your config
Retired: No longer included or supported.

Language(s)	Status	Switch (for `install_gadget.py`)	Adapter (for `:VimspectorInstall`)	Dependencies
C, C++, Rust, Jai, etc.	Tested	`--all` or `--enable-c` (or cpp)	vscode-cpptools	mono-core
C, C++, Rust, Jai, etc.	Tested	`--enable-rust`, `--enable-c`, etc.	CodeLLDB	none
Python	Tested	`--all` or `--enable-python`	debugpy	Python 3
Go	Tested	`--enable-go`	delve	Go 1.16+
TCL	Supported	`--all` or `--enable-tcl`	tclpro	TCL 8.5
Bourne Shell	Supported	`--all` or `--enable-bash`	vscode-bash-debug	Bash v??
Lua	Tested	`--all` or `--enable-lua`	local-lua-debugger-vscode	Node >=12.13.0, Npm, Lua interpreter
Node.js	Supported	`--force-enable-node`	vscode-js-debug	Node >= 18
Node.js (legacy)	Supported	`--force-enable-node_legacy`	vscode-node-debug2	6 < Node < 12, Npm
Javascript	Supported	`--force-enable-chrome`	debugger-for-chrome	Chrome
Javascript	Supported	`--force-enable-firefox`	vscode-firefox-debug	Firefox
Java	Supported	`--force-enable-java`	vscode-java-debug	Compatible LSP plugin (see later)
PHP	Experimental	`--force-enable-php`	vscode-php-debug	Node, PHP, XDEBUG
C# (dotnet core)	Tested	`--force-enable-csharp`	netcoredbg	DotNet core
F#, VB, etc.	Supported	`--force-enable-[fsharp,vbnet]`	netcoredbg	DotNet core
Go (legacy)	Legacy	`--enable-go`	vscode-go	Node, Go, Delve
Python 2	Legacy	`--force-enable-python2`	debugpy-python2	Python 2.7

Other languages

Vimspector should work for any debug adapter that works in Visual Studio Code.

To use Vimspector with a language that's not "built-in", see this wiki page.

Installation

Quick Start

There are 3 installation methods:

Using a release tarball and Vim packages
Using a repo clone and Vim packages
Using a plugin manager

Method 1: Using a release tarball and Vim packages

Release tarballs come with debug adapters for the default languages pre-packaged. To use a release tarball:

Check the dependencies

Untar the release tarball for your OS into $HOME/.vim/pack:

$ mkdir -p $HOME/.vim/pack
$ curl -L <url> | tar -C $HOME/.vim/pack zxvf -

Add packadd! vimspector to your .vimrc
(optionally) Enable the default set of mappings:
```
let g:vimspector_enable_mappings = 'HUMAN'
```
Configure your project's debug profiles (create .vimspector.json, or set g:vimspector_configurations) - see the reference guide

Method 2: Using a repo clone, Vim packages and select gadgets to be installed

Check the dependencies
Install the plugin as a Vim package. See :help packages.
Add packadd! vimspector to your .vimrc
Install some 'gadgets' (debug adapters) - see here for installation commands and select gadgets to install
Configure your project's debug profiles (create .vimspector.json, or set g:vimspector_configurations) - see the reference guide

Method 3: Using a plugin manager

Check the dependencies
See the plugin manager's docs and install the plugin
For Vundle, use:
```
Plugin 'puremourning/vimspector'
```
Install some 'gadgets' (debug adapters) - see here for installation commands and select gadgets to install
Configure your project's debug profiles (create .vimspector.json, or set g:vimspector_configurations) - see the reference guide

The following sections expand on the above brief overview.

Dependencies

Vimspector requires:

One of:
- Vim 8.2.4797 or later "huge" build compiled with Python 3.10 or later
- Neovim 0.8 with Python 3.10 or later
One of the following operating systems:
- Linux
- macOS Mojave or later
- Windows (experimental)

Which Linux versions? I only test on Ubuntu 20.04 and later and RHEL 7.

Neovim limitations

neovim doesn't implement mouse hover balloons. Instead there is the <Plug>VimspectorBalloonEval mapping. There is no default mapping for this, so I recommend something like this to get variable display in a popup:

" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)

" for normal mode - the word under the cursor
nmap <Leader>di <Plug>VimspectorBalloonEval
" for visual mode, the visually selected text
xmap <Leader>di <Plug>VimspectorBalloonEval

Windows differences

The following features are not implemented for Windows:

Tailing the vimspector log in the Output Window.

Trying it out

If you just want to try out vimspector without changing your vim config, there are example projects for a number of languages in support/test, including:

Python (support/test/python/simple_python)
Go (support/test/go/hello_world and support/test/go/name-starts-with-vowel)
Nodejs (support/test/node/simple)
Chrome/Firefox (support/test/web/)
etc.

To test one of these out, cd to the directory and run:

vim -Nu /path/to/vimspector/tests/vimrc --cmd "let g:vimspector_enable_mappings='HUMAN'"

Then press <F5>.

There's also a C++ project in tests/testdata/cpp/simple/ with a Makefile which can be used to check everything is working. This is used by the regression tests in CI so should always work, and is a good way to check if the problem is your configuration rather than a bug.

Cloning the plugin

If you're not using a release tarball, you'll need to clone this repo to the appropriate place.

Clone the plugin

There are many Vim plugin managers, and I'm not going to state a particular preference, so if you choose to use one, follow the plugin manager's documentation. For example, for Vundle, use:

Plugin 'puremourning/vimspector'

If you don't use a plugin manager already, install vimspector as a Vim package by cloning this repository into your package path, like this:

$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector

Configure vimspector in your .vimrc, for example to enable the standard mappings:

let g:vimspector_enable_mappings = 'HUMAN'

Load vimspector at runtime. This can also be added to your .vimrc after configuring vimspector:

packadd! vimspector

See support/doc/example_vimrc.vim for a minimal example.

Install some gadgets

Vimspector is a generic client for Debug Adapters. Debug Adapters (referred to as 'gadgets' or 'adapters') are what actually do the work of talking to the real debuggers.

In order for Vimspector to be useful, you need to have some adapters installed.

There are a few ways to do this:

If you downloaded a tarball, gadgets for main supported languages are already installed for you.
Using :VimspectorInstall <adapter> <args...> (use TAB wildmenu to see the options, also accepts any install_gadget.py option)
Using python3 install_gadget.py <args> (use --help to see all options)
Attempting to launch a debug configuration; if the configured adapter can't be found, vimspector will suggest installing one.
Using :VimspectorUpdate to install the latest supported versions of the gadgets.

Here's a demo of doing some installs and an upgrade:

Both install_gadget.py and :VimspectorInstall do the same set of things, though the default behaviours are slightly different. For supported languages, they will:

Download the relevant debug adapter at a version that's been tested from the internet, either as a 'vsix' (Visusal Studio plugin), or clone from GitHub. If you're in a corporate environment and this is a problem, you may need to install the gadgets manually.
Perform any necessary post-installation actions, such as:
- Building any binary components
- Ensuring scripts are executable, because the VSIX packages are usually broken in this regard.
- Set up the gadgetDir symlinks for the platform.

For example, to install the tested debug adapter for a language, run:

To install	Script	Command
`<adapter>`		`:VimspectorInstall <adapter>`
`<adapter1>`, `<adapter2>`, ...		`:VimspectorInstall <adapter1> <adapter2> ...`
`<language>`	`./install_gadget.py --enable-<language> ...`	`:VimspectorInstall --enable-<language> ...`
Supported adapters	`./install_gadget.py --all`	`:VimspectorInstall --all`
Supported adapters, but not TCL	`./install_gadget.py --all --disable-tcl`	`:VimspectorInstall --all --disable-tcl`
Supported and experimental adapters	`./install_gadget.py --all --force-all`	`:VimspectorInstall --all`
Adapter for specific debug config		Suggested by Vimspector when starting debugging

VimspectorInstall and VimspectorUpdate commands

:VimspectorInstall runs install_gadget.py in the background with some of the options defaulted.

:VimspectorUpdate runs install_gadget.py to re-install (i.e. update) any gadgets already installed in your .gadgets.json.

The output is minimal, to see the full output add --verbose to the command, as in :VimspectorInstall --verbose ... or :VimspectorUpdate --verbose ....

If the installation is successful, the output window is closed (and the output lost forever). Use a ! to keep it open (e.g. :VimspectorInstall! --verbose --all or :VimspectorUpdate! (etc.).

If you know in advance which gadgets you want to install, for example so that you can reproduce your config from source control, you can set g:vimspector_install_gadgets to a list of gadgets. This will be used when:

Running :VimspectorInstall with no arguments, or
Running :VimspectorUpdate

For example:

let g:vimspector_install_gadgets = [ 'debugpy', 'vscode-cpptools', 'CodeLLDB' ]

install_gadget.py

By default install_gadget.py will overwrite your .gadgets.json with the set of adapters just installed, whereas :VimspectorInstall will update it, overwriting only newly changed or installed adapters.

If you want to just add a new adapter using the script without destroying the existing ones, add --update-gadget-config, as in:

$ ./install_gadget.py --enable-tcl
$ ./install_gadget.py --enable-rust --update-gadget-config
$ ./install_gadget.py --enable-java --update-gadget-config

If you want to maintain configurations outside of the vimspector repository (this can be useful if you have custom gadgets or global configurations), you can tell the installer to use a different basedir, then set g:vimspector_base_dir to point to that directory, for example:

$ ./install_gadget.py --basedir $HOME/.vim/vimspector-config --all --force-all

Then add this to your .vimrc:

let g:vimspector_base_dir=expand( '$HOME/.vim/vimspector-config' )

When using :VimspectorInstall, the g:vimspector_base_dir setting is respected unless --basedir is manually added (not recommended).

See --help for more info on the various options.

Manual gadget installation

If the language you want to debug is not in the supported list above, you can probably still make it work, but it's more effort.

You essentially need to get a working installation of the debug adapter, find out how to start it, and configure that in an adapters entry in either your .vimspector.json or in .gadgets.json or in g:vimspector_adapters.

The simplest way in practice is to install or start Visual Studio Code and use its extension manager to install the relevant extension. You can then configure the adapter manually in the adapters section of your .vimspector.json or in a gadgets.json or in g:vimspector_adapters.

PRs are always welcome to add supported languages (which roughly translates to updating python/vimspector/gadgets.py and testing it).

The gadget directory

Vimspector uses the following directory by default to look for a file named .gadgets.json: </path/to/vimspector>/gadgets/<os>.

This path is exposed as the vimspector variable ${gadgetDir}. This is useful for configuring gadget command lines.

Where os is one of:

macos
linux
windows (though note: Windows is not supported)

The format is the same as .vimspector.json, but only the adapters key is used:

Example:

{
  "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"
    }
  }
}

The gadget file is automatically written by install_gadget.py (or :VimspectorInstall).

Vimspector will also load any files matching: </path/to/vimspector>/gadgets/<os>/.gadgets.d/*.json. These have the same format as .gadgets.json but are not overwritten when running install_gadget.py.

Upgrade

After updating the Vimspector code (either via git pull or whatever package manager), run :VimspectorUpdate to update any already-installed gadgets.

About

Background

The motivation is that debugging in Vim is a pretty horrible experience, particularly if you use multiple languages. With pyclewn no more and the built-in termdebug plugin limited to gdb, I wanted to explore options.

While Language Server Protocol is well known, the Debug Adapter Protocol is less well known, but achieves a similar goal: language agnostic API abstracting debuggers from clients.

The aim of this project is to provide a simple but effective debugging experience in Vim for multiple languages, by leveraging the debug adapters that are being built for Visual Studio Code.

The ability to do remote debugging is a must. This is key to my workflow, so baking it in to the debugging experience is a top bill goal for the project. So vimspector has first-class support for executing programs remotely and attaching to them. This support is unique to vimspector and on top of (complementary to) any such support in actual debug adapters.

What Vimspector is not

Vimspector is a vim UI on top of the Debug Adapter Protocol. It's intended to be high level and convenient for day-to-day debugging tasks.

Vimspector is not:

a debugger! It's just the UI and some glue.
fast. It's abstractions all the way down. If you want a fast, native debugger, there are other options.
comprehensive. It's limited by DAP, and limited by my time. I implement the features I think most users will need, not every feature possible.
for everyone. Vimspector intentionally provides a "one size fits all" UI and aproach. This means that it can only provide essential/basic debugging features for a given language. This makes it convenient for everyday usage, but not ideal for power users or those with very precise or specific requirements. See motivation for more info.

Status

Vimspector is a work in progress, and any feedback/contributions are more than welcome.

The backlog can be viewed on Trello.

Experimental

The plugin is currently experimental. That means that any part of it can (and probably will) change, including things like:

breaking changes to the configuration
keys, layout, functionality of the UI

However, I commit to only doing this in the most extreme cases and to announce such changes on Gitter well in advance. There's nothing more annoying than stuff just breaking on you. I get that.

Motivation

A message from the author about the motivation for this plugin:

Many development environments have a built-in debugger. I spend an inordinate amount of my time in Vim. I do all my development in Vim and I have even customised my workflows for building code, running tests etc.

For many years I have observed myself, friends and colleagues have been writing printf, puts, print, etc. debugging statements in all sorts of files simply because there is no easy way to run a debugger for whatever language we happen to be developing in.

I truly believe that interactive, graphical debugging environments are the best way to understand and reason about both unfamiliar and familiar code, and that the lack of ready, simple access to a debugger is a huge hidden productivity hole for many.

Don't get me wrong, I know there are literally millions of developers out there that are more than competent at developing without a graphical debugger, but I maintain that if they had the ability to just press a key and jump into the debugger, it would be faster and more enjoyable that just cerebral code comprehension.

I created Vimspector because I find changing tools frustrating. gdb for c++, pdb for python, etc. Each has its own syntax. Each its own lexicon. Each its own foibles.

I designed the configuration system in such a way that the configuration can be committed to source control so that it just works for any of your colleagues, friends, collaborators or complete strangers.

I made remote debugging a first-class feature because that's a primary use case for me in my job.

With Vimspector I can just hit <F5> in all of the languages I develop in and debug locally or remotely using the exact same workflow, mappings and UI. I have integrated this with my Vim in such a way that I can hit a button and run the test under the cursor in Vimspector. This kind of integration has massively improved my workflow and productivity. It's even made the process of learning a new codebase... fun.

- Ben Jackson, Creator.

License

Apache 2.0

Sponsorship

If you like Vimspector so much that you're wiling to part with your hard-earned cash, please consider donating to one of the following charities, which are meaningful to the author of Vimspector (in order of preference):

Mappings

By default, vimspector does not change any of your mappings. Mappings are very personal and so you should work out what you like and use vim's powerful mapping features to set your own mappings. To that end, Vimspector defines the following <Plug> mappings:

Mapping	Function	API
`<Plug>VimspectorContinue`	When debugging, continue. Otherwise start debugging.	`vimspector#Continue()`
`<Plug>VimspectorStop`	Stop debugging.	`vimspector#Stop()`
`<Plug>VimpectorRestart`	Restart debugging with the same configuration.	`vimspector#Restart()`
`<Plug>VimspectorPause`	Pause debuggee.	`vimspector#Pause()`
`<Plug>VimspectorBreakpoints`	Show/hide the breakpoints window	`vimspector#ListBreakpoints()`
`<Plug>VimspectorToggleBreakpoint`	Toggle line breakpoint on the current line.	`vimspector#ToggleBreakpoint()`
`<Plug>VimspectorToggleConditionalBreakpoint`	Toggle conditional line breakpoint or logpoint on the current line.	`vimspector#ToggleBreakpoint( { trigger expr, hit count expr } )`
`<Plug>VimspectorAddFunctionBreakpoint`	Add a function breakpoint for the expression under cursor	`vimspector#AddFunctionBreakpoint( '<cexpr>' )`
`<Plug>VimspectorGoToCurrentLine`	Reset the current program counter to the current line	`vimspector#GoToCurrentLine()`
`<Plug>VimspectorRunToCursor`	Run to Cursor	`vimspector#RunToCursor()`
`<Plug>VimspectorStepOver`	Step Over	`vimspector#StepOver()`
`<Plug>VimspectorStepInto`	Step Into	`vimspector#StepInto()`
`<Plug>VimspectorStepOut`	Step out of current function scope	`vimspector#StepOut()`
`<Plug>VimspectorDisassemble`	Show disassembly. Enable instruction stepping	`vimspector#ShowDisassembly()`
`<Plug>VimspectorUpFrame`	Move up a frame in the current call stack	`vimspector#UpFrame()`
`<Plug>VimspectorDownFrame`	Move down a frame in the current call stack	`vimspector#DownFrame()`
`<Plug>VimspectorJumpToNextBreakpoint`	Move Cursor to the next breakpoint in current file	`vimspector#JumpToNextBreakpoint()`
`<Plug>VimspectorJumpToPreviousBreakpoint`	Move Cursor to the previous breakpoint in current file	`vimspector#JumpToPreviousBreakpoint()`
`<Plug>VimspectorJumpToProgramCounter`	Move Cursor to the program counter in the current frame	`vimspector#JumpToProgramCounter()`
`<Plug>VimspectorBalloonEval`	Evaluate expression under cursor (or visual) in popup	internal

These map roughly 1-1 with the API functions below.

For example, if you want <F5> to start/continue debugging, add this to some appropriate place, such as your vimrc (hint: run :e $MYVIMRC).

nmap <F5> <Plug>VimspectorContinue

In addition, many users probably want to only enable certain Vimspector mappings while debugging is active. This is also possible, though it requires writing some vimscipt.

That said, many people are familiar with particular debuggers, so the following mappings can be enabled by setting g:vimspector_enable_mappings to the specified value.

Visual Studio / VSCode

To use Visual Studio-like mappings, add the following to your vimrc before loading vimspector:

let g:vimspector_enable_mappings = 'VISUAL_STUDIO'

Key	Mapping	Function
`F5`	`<Plug>VimspectorContinue`	When debugging, continue. Otherwise start debugging.
`Shift F5`	`<Plug>VimspectorStop`	Stop debugging.
`Ctrl Shift F5`	`<Plug>VimspectorRestart`	Restart debugging with the same configuration.
`F6`	`<Plug>VimspectorPause`	Pause debuggee.
`F8`	`<Plug>VimspectorJumpToNextBreakpoint`	Jump to next breakpoint in the current file.
`Shift F8`	`<Plug>VimspectorJumpToPreviousBreakpoint`	Jump to previous breakpoint in the current file.
`F9`	`<Plug>VimspectorToggleBreakpoint`	Toggle line breakpoint on the current line.
`Shift F9`	`<Plug>VimspectorAddFunctionBreakpoint`	Add a function breakpoint for the expression under cursor
`F10`	`<Plug>VimspectorStepOver`	Step Over
`Ctrl F10`	`<Plug>VimspectorRunToCursor`	Run to cursor*
`F11`	`<Plug>VimspectorStepInto`	Step Into
`Shift F11`	`<Plug>VimspectorStepOut`	Step out of current function scope
`Alt 8`	`<Plug>VimspectorDisassemble`	Show disassembly

NOTE: Some mappings, such as ctrl and F-keys may not work depending on your terminal, keyboard, windowing system and all sorts of other things. See :help modifyOtherKeys and other sources. If you are unable to make this work, just use the "human mode" mappings.

Human Mode

If, like me, you only have 2 hands and 10 fingers, you probably don't like Ctrl-Shift-F keys. Also, if you're running in a terminal, there's a real possibility of terminfo being wrong for shifted-F-keys, particularly if your TERM is screen-256color. If these issues (number of hands, TERM variables) are unfixable, try the following mappings, by adding the following before loading vimspector:

let g:vimspector_enable_mappings = 'HUMAN'

Key	Mapping	Function
`F5`	`<Plug>VimspectorContinue`	When debugging, continue. Otherwise start debugging.
`F3`	`<Plug>VimspectorStop`	Stop debugging.
`F4`	`<Plug>VimspectorRestart`	Restart debugging with the same configuration.
`F6`	`<Plug>VimspectorPause`	Pause debuggee.
`F9`	`<Plug>VimspectorToggleBreakpoint`	Toggle line breakpoint on the current line.
`<leader>F9`	`<Plug>VimspectorToggleConditionalBreakpoint`	Toggle conditional line breakpoint or logpoint on the current line.
`F8`	`<Plug>VimspectorAddFunctionBreakpoint`	Add a function breakpoint for the expression under cursor
`<leader>F8`	`<Plug>VimspectorRunToCursor`	Run to Cursor
`F10`	`<Plug>VimspectorStepOver`	Step Over
`F11`	`<Plug>VimspectorStepInto`	Step Into
`F12`	`<Plug>VimspectorStepOut`	Step out of current function scope

In addition, I recommend adding a mapping to <Plug>VimspectorBalloonEval, in normal and visual modes, for example:

" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)

" for normal mode - the word under the cursor
nmap <Leader>di <Plug>VimspectorBalloonEval
" for visual mode, the visually selected text
xmap <Leader>di <Plug>VimspectorBalloonEval

You may also wish to add mappings for navigating up/down the stack, toggling the breakpoints window, and showing disassembly, for example:

nmap <LocalLeader><F11> <Plug>VimspectorUpFrame
nmap <LocalLeader><F12> <Plug>VimspectorDownFrame
nmap <LocalLeader>B     <Plug>VimspectorBreakpoints
nmap <LocalLeader>D     <Plug>VimspectorDisassemble

Usage and API

This section defines detailed usage instructions, organised by feature. For most users, the mappings section contains the most common commands and default usage. This section can be used as a reference to create your own mappings or custom behaviours.

All the below instructions assume a single debugging session. For deatils on how to debug multiple independent apps at the same time, see [multiple debugging sessions][#multiple-debugging-sessions].

Launch and attach by PID:

Create .vimspector.json. See below.
:call vimspector#Launch() and select a configuration.

Launching a new session makes it the active [debugging session][#multiple-debugging-sessions].

Picking a PID

If the debug adapter configuration uses pidProperty, and you make an attach request, then you will be asked to enter a PID (process ID) to attach to.

To make this easier, Vimspector supplies a little utility for listing PIDs. It's like a very very simple clone of ps but works on all the supported platforms. See its README for instructions on setting it up.

In short:

If you used a tarball installation, you don't need to do anything.
Otherwise, run go build in the support/vimspector_process_list directory

If Vimspector is able to find this app, it will try to list all processes owned by the current user by default.

Alternatively (preferably), you can use a special form of variable expansion called ${PickProcess(\"binaryName\")}. The version of this call will list all processes for the current user that match this binary name.

For example:

"Attach": {
  "adapter": "CodeLLDB",
  "configuration": {
    "request": "attach",
    "program": "${workspaceRoot}/Jails",
    "pid": "${PickProcess(\"jails\")}"
  }
}

This will list each matching processes, its parent process, start time and working directory. It's looks something like this:

PID   PPID           CWD                                           START
52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24
Enter Process ID:

You then enter the PID and hit <CR>.

You can even replace the process picker with your own function. If you define some function and set g:vimspector_custom_process_picker_func to the name of that function. It will be passed any arguments passed to the PickProcess expansion function. It will also be used whenever a pidProperty is specified, so it must also handle no arguments (use ... as the formal arguments for the function, see :help ...).

For example, to use fzf along with the supplied vimspector_process_list:

function! CustomPickProcess( ... ) abort
  let ps = $HOME .. '/.vim/bundle/vimspector/support/vimspector_process_list/vimspector_process_list'
  " a:0 is number of args
  " a:1 is the optional binary name
  if a:0 > 0
    let ps .= ' ^' . a:1 . '$'
  endif

  let line_selected = fzf#run( {
      \ 'source': ps,
      \ 'options': '--header-lines=1  '
      \          . '--prompt="Select Process: " '
      \ ,
      \
      \ } )[ 0 ]
  if empty( line_selected)
    return 0
  endif
  let pid = split( line_selected )[ 0 ]
  return str2nr( pid )
endfunction


let g:vimspector_custom_process_picker_func = 'CustomPickProcess'

Or to use fzf with the output of 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'

Launch with options

To launch a specific debug configuration, or specify replacement variables for the launch, you can use:

:call vimspector#LaunchWithSettings( dict )

The argument is a dict with the following keys:

configuration: (optional) Name of the debug configuration to launch
<anything else>: (optional) Name of a variable to set

This allows for some integration and automation. For example, if you have a configuration named Run Test that contains a replacement variable named ${Test} you could write a mapping which ultimately executes:

vimspector#LaunchWithSettings( #{ configuration: 'Run Test'
                                \ Test: 'Name of the test' } )

This would start the Run Test configuration with ${Test} set to 'Name of the test' and Vimspector would not prompt the user to enter or confirm these things.

See our YouCompleteMe integration guide for another example where it can be used to specify the port to connect the java debugger

To launch with an ad-hoc config you can use:

call vimspector#LaunchWithConfigurations( dict )

The argument is a dict which is the configurations section of a .vimspector file. Pass one configuration in and that will be selected as the one to run. For example:

   let pid = <some_expression>
   call vimspector#LaunchWithConfigurations({
               \  "attach": {
               \    "adapter": "netcoredbg",
               \    "configuration": {
               \      "request": "attach",
               \      "processId": pid
               \    }
               \  }
               \})

This would launch the debugger and attach to the specified process without the need to have a local .vimspector file on disk. The ${workspaceRoot} variable will point to the parent folder of the file that is currently open in vim.

Debug configuration selection

Vimspector uses the following logic to choose a configuration to launch:

If a configuration was specified in the launch options (as above), use that.
Otherwise if there's only one configuration and it doesn't have autoselect set to false, use that.
Otherwise if there's exactly one configuration with default set to true and without autoselect set to false, use that.
Otherwise, prompt the user to select a configuration.

See the reference guide for details.

Get configurations

Use vimspector#GetConfigurations() to get a list of configurations for the filetype of the current buffer

For example, to get an array of configurations and fuzzy matching on the result

:call matchfuzzy(vimspector#GetConfigurations(), "test::case_1")

Breakpoints

See the mappings section for the default mappings for working with breakpoints. This section describes the full API in vimscript functions.

Breakpoints are associated with the current [debugging session][#multiple-debugging-sessions]. When switching between sessions, the breakpont signs for the previous session are removed and the breakpoints for the newly activated session are displayed. While it might be useful to see breakpoints for all sessions, this can be very confusing.

Breakpoints Window

Use :VimspectorBreakpoints or map something to <Plug>VimspectorBreakpoints to open the breakpoints view. From here you can list, jump to delete, add and toggle breakpoints.

I recommend a mapping like this to toggle the breakpoints window:

nmap <Leader>db <Plug>VimspectorBreakpoints

The following mappings apply by default in the breakpoints window:

t, <F9> - toggle, i.e. enable/disable breakpoint
T - toggle, i.e. enable/disable ALL breakpoints
dd, <Del> - delete the current breakpoint
cc, C - edit the current breakpoint options
i, a, o - add a new line breakpoint
I, A, O - add a new function breakpoint
<Enter> or double-click - jump to the line breakpoint

A WinBar is provided (where supported) too. This adds functions like saving/restoring sessions, clearing all breakpoints, and resetting the exception breakpoints options.

Line breakpoints

The simplest and most common form of breakpoint is a line breakpoint. Execution is paused when the specified line is executed.

For most debugging scenarios, users will just hit <F9> to create a line breakpoint on the current line and <F5> to launch the application.

Conditional breakpoints and logpoints

Some debug adapters support conditional breakpoints. Note that vimspector does not tell you if the debugger doesn't support conditional breakpoints (yet). A conditional breakpoint is a breakpoint which only triggers if some expression evaluates to true, or has some other constraints met.

Some of these functions above take a single optional argument which is a dictionary of options. The dictionary can have the following keys:

condition: An optional expression evaluated to determine if the breakpoint should fire. Not supported by all debug adapters. For example, to break when abc is 10, enter something like abc == 10, depending on the language.
hitCondition: An optional expression evaluated to determine a number of times the breakpoint should be ignored. Should (probably?) not be used in combination with condition. Not supported by all debug adapters. For example, to break on the 3rd time hitting this line, enter 3.
logMessage: An optional string to make this breakpoint a "logpoint" instead. When triggered, this message is printed to the console rather than interrupting execution. You can embed expressions in braces {like this}, for example #{ logMessage: "Iteration {i} or {num_entries / 2}" }

In each case expressions are evaluated by the debugger, so should be in whatever dialect the debugger understands when evaluating expressions.

When using the <leader><F9> mapping, the user is prompted to enter these expressions in a command line (with history).

Exception breakpoints

Exception breakpoints typically fire when an exception is throw or other error condition occurs. Depending on the debugger, when starting debugging, you may be asked a few questions about how to handle exceptions. These are "exception breakpoints" and vimspector remembers your choices while Vim is still running.

Typically you can accept the defaults (just keep pressing <CR>!) as most debug adapter defaults are sane, but if you want to break on, say uncaught exception then answer Y to that (for example).

You can configure your choices in the .vimspector.json. See the configuration guide for details on that.

API Summary

NOTE: Previously, ToggleBreakpoint would cycle between 3 states: enabled, disabled, deleted. Many users found the 'disabled' state was rarely useful, so the behaviour has been changed. ToggleBreakpoint always creates or deletes a breakpoint. If you wish to 'disable' breakpoints, use the breakpoints window and 'toggle' (t) from there.

Use vimspector#ToggleBreakpoint( { options dict } ) to set/delete a line breakpoint. The argument is optional (see below).
Use vimspector#AddFunctionBreakpoint( '<name>', { options dict} ) to add a function breakpoint. The second argument is optional (see below).
Use vimspector#SetLineBreakpoint( file_name, line_num, { options dict } ) to set a breakpoint at a specific file/line. The last argument is optional (see below)
Use vimspector#ClearLineBreakpoint( file_name, line_num ) to remove a breakpoint at a specific file/line
Use vimspector#ClearBreakpoints() to clear all breakpoints
Use vimspector#ResetExceptionBreakpoints() to clear the exception breakpoints configuration and re-anser the various questions like "Break on C++ Throw"
Use :VimspectorMkSession and :VimspectorLoadSession to save and restore breakpoints
call vimspector#ListBreakpoints() - toggle breakpoints window
call vimspector#BreakpointsAsQuickFix() - return the current set of breakpoints in vim quickfix format

Examples:

call vimspector#ToggleBreakpoint() - toggle breakpoint on current line
call vimspector#SetLineBreakpoint( 'some_file.py', 10 ) - set a breakpoint on some_filepy:10
call vimspector#AddFunctionBreakpoint( 'main' ) - add a function breakpoint on the main function
call vimspector#ToggleBreakpoint( { 'condition': 'i > 5' } ) - add a breakpoint on the current line that triggers only when i > 5 is true
call vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i > 5' } ) - add a breakpoint at some_file.py:10 that triggers only when i > 5 is true
call vimspector#ClearLineBreakpoint( 'some_file.py', 10 ) - delete the breakpoint at some_file.py:10
call vimspector#ClearBreakpoints() - clear all breakpoints
VimspectorMkSession - create .vimspector.session
VimspectorLoadSession - read .vimspector.session
VimspectorMkSession my_session_file - create my_session_file
VimspectorLoadSession my_session_file - read my_session_file

Instruction breakpoints

NOTE: Experimental feature, which may change significantly in future based on user feedback.

Instruction breakpoints can be added from the disassembly window in the same way that you add line breakpoints in the code window. The same mappings and functions work for adding and toggling them. Where supported by the debug adapter, you can even create logpoints and conditional breakpoints this way.

Currently, instruction breakpoints are internally modelled as line breakpoints against the buffer containing the disassembly, but that may change in future, so please don't rely on this.

Instruction breakpoints are also visible from and can be deleted/disabled from the breakpoints window.

Currently, instruction breakpoints are automatically cleared when the debug session ends. The reason for this is that the addresses can't be guaranteed to be valid for any other debug session. However, this may also change in future.

Clear breakpoints

Use vimspector#ClearBreakpoints() to clear all breakpoints including the memory of exception breakpoint choices.

Run to Cursor

Use vimspector#RunToCursor or <leader><F8>: this creates a temporary breakpoint on the current line, then continues execution, clearing the breakpoint when it is hit.

Go to current line

Use vimspector#GoToCurrentLine() or some mapping to <Plug>VimspectorGoToCurrentLine to jump the current execution to the line your cursor is currently on.

Where supported this can be useful to re-run sections of code or skip over them entirely.

If there are multiple possible "targets" on the current line, you're prompted to pick one.

Save and restore

Vimspector can save and restore breakpoints (and some other stuff) to a session file. The following commands exist for that:

VimspectorMkSession [file/dir name] - save the current set of line breakpoints, logpoints, conditional breakpoints, function breakpoints and exception breakpoint filters to the supplied session file or the default file in the supplied directory.
VimspectorLoadSession [file/dir name] - read breakpoints from the session file supplied or the default file in the supplied directory and replace any currently set breakpoints. Prior to loading, all current breakpoints are cleared (as if vimspector#ClearLineBreakpoints() was called).

In both cases, the file/dir name argument is optional. By default, the file is named .vimspector.session, but this can be changed globally by setting g:vimspector_session_file_name to something else, or by manually specifying a path when calling the command. If you supply a directory, the default or configured session file name is read fron or written to that directory. Othewise, the file is read based on the currently open buffer or written to the current working directory.

Advanced users may wish to automate the process of loading and saving, for example by adding VimEnter and VimLeave autocommands. It's recommended in that case to use silent! to avoid annoying errors if the file can't be read or written.

The simplest form of automation is to load the vimspector session whenever you start vim with a session file. This is as simple as doing this:

$ echo silent VimspectorLoadSession > Sessionx.vim

See :help mksession for details of the *x.vim file. You can also do something like this using SessionLoadPost:

autocmd SessionLoadPost * silent! VimspectorLoadSession

Stepping

Step in/out, finish, continue, pause etc. using the WinBar, or mappings.
Stepping is contextual. By default, stepping is statement granularity. But if your cursor is in the disassembly window, then stepping defaults to instruction granularity.
If you really want to, the API is vimspector#StepInto() etc.. There are also vimspector#StepSOver() and vimspector#StepIOver() etc. variants for statement and instruction granularity respectively.

Variables and scopes

Current scope shows values of locals.
Use <CR>, or double-click with left mouse to expand/collapse (+, -).
Set the value of the variable with <C-CR> (control + <CR>) or <leader><CR> (if modifyOtherKeys doesn't work for you)
View the type of the variable via mouse hover.
When changing the stack frame the locals window updates.
While paused, hover to see values.

Scopes and variables are represented by the buffer vimspector.Variables.

If you prefer a more verbose display for variables and watches, then you can let g:vimspector_variables_display_mode = 'full'. By default only the name and value are displayed, with other data available from hovering the mouse or triggering <Plug>VimspectorBalloonEval on the line containing the value in the variables (or watches) window.

Variable or selection hover evaluation

All rules for Variables and scopes apply plus the following:

With mouse enabled, hover over a variable and get the value it evaluates to. This applies to the variables and watches windows too, and allows you to view the type of the value.
Use your mouse to perform a visual selection of an expression (e.g. a + b) and get its result.
Make a normal mode (nmap) and visual mode (xmap) mapping to <Plug>VimspectorBalloonEval to manually trigger the popup.
- Set the value of the variable with <C-CR> (control + <CR>) or <leader><CR> (if modifyOtherKeys doesn't work for you)
- Use regular navigation keys (j, k) to choose the current selection; <Esc> (or leave the tooltip window) to close the tooltip.

You can disable automatic hovering popup by settings g:vimspector_enable_auto_hover=0 before starting the debug session. You can then map something to <Plug>VimspectorBalloonEval and trigger it manually.

Watches

The watch window is used to inspect variables and expressions. Expressions are evaluated in the selected stack frame which is "focussed"

The watches window is a prompt buffer, where that's available. Enter insert mode to add a new watch expression.

Add watches to the variables window by entering insert mode and typing the expression. Commit with <CR>.
Alternatively, use :VimspectorWatch <expression>. Tab-completion for expression is available in some debug adapters.
View the type of the variable via mouse hover.
Expand result with <CR>, or double-click with left mouse.
Set the value of the variable with <C-CR> (control + <CR>) or <leader><CR> (if modifyOtherKeys doesn't work for you)
Delete with <DEL>.

The watches are represented by the buffer vimspector.Watches.

Watch autocompletion

The watch prompt buffer has its omnifunc set to a function that will calculate completion for the current expression. This is trivially used with <Ctrl-x><Ctrl-o> (see :help ins-completion), or integrated with your favourite completion system. The filetype in the buffer is set to VimspectorPrompt.

For YouCompleteMe, the following config works well:

let g:ycm_semantic_triggers =  {
  \   'VimspectorPrompt': [ '.', '->', ':', '<' ]
}

Disassembly

Dispplay disassembly around current PC
Step over/into/out by instruction (contextually, or using the WinBar)
:VimspectorDisassemble, vimspector#ShowDisassembly() or <Plug>VimspectorDisassemble

Some debug adapters (few!) support disassembly. The way this works in DAP is a little wierd, but in practice vimspector will ask to disassemble a number of instructions around the current stack frame's PC. This is then shown in a window with a WinBar similar to the Code window, but with instruction stepping granularity. There's a sign for the current instruction and the syntax highighting defaults to "asm" which mostly works ok for x86 and ARM.

As mentioned above, when your current window is the disassembly windows and you use the default "step" commands (e.g. <F10>), the stepping is automatically chnged to per-instruction rather than per statement.

Each time the process stops, vimspector requests about 2 windows full of instructions around the current PC. To see more, you can scroll the window. Vimspector will page in an extra screenful of instructions when the window scrolls to the top or near the bottom. This isn't perfect. Sometimes you have to scroll a bit more to make it page in (e.g. ctrl-e ctrl-y at the top). This is not ideal, and may be improved in future.

You can control the intial height of the disassembly window with let g:vimspector_disassembly_height = 10 (or whatver number of lines).

The filetype (and syntax) of the buffers in the disassembly window is vimspector-disassembly. You can use FileType autocommands to customise things like the syntax highlighting.

NOTE: This feature is experimental and may change in any way based on user feedback.

Dump memory

Some debug adapters provide a way to dump process memory associated with variables. This can be done from the Variables and Watches windows with:

The WinBar option "Dump"
<leader>m mapping (by default, can be customised)
vimspector#ReadMemory() function

On doing this, you're asked to enter a number of bytes to read (from the location associated with the current cursor line) and an offset from that location. A new buffer is displayed in the Code Window containing a memory dump in hex and ascii, similar to the output of xxd.

NOTE: This feature is experimental and may change in any way based on user feedback.

Stack Traces

The stack trace window shows the state of each program thread. Threads which are stopped can be expanded to show the stack trace of that thread.

Often, but not always, all threads are stopped when a breakpoint is hit. The status of a thread is show in parentheses after the thread's name. Where supported by the underlying debugger, threads can be paused and continued individually from within the Stack Trace window.

A particular thread, highlighted with the CursorLine highlight group is the "focussed" thread. This is the thread that receives commands like "Step In", "Step Out", "Continue" and "Pause" in the code window. The focussed thread can be changed manually to "switch to" that thread.

Use <CR>, or double-click with left mouse to expand/collapse a thread stack trace, or use the WinBar button.
Use <CR>, or double-click with left mouse on a stack frame to jump to it.
Use the WinBar or vimspector#PauseContinueThread() to individually pause or continue the selected thread.
Use the "Focus" WinBar button, <leader><CR> or vimspector#SetCurrentThread() to set the "focussed" thread to the currently selected one. If the selected line is a stack frame, set the focussed thread to the thread of that frame and jump to that frame in the code window.
The current frame when a breakpoint is hit or if manual jumping is also highlighted.

The stack trace is represented by the buffer vimspector.StackTrace.

Child sessions

If there are child debug sessions, such as where the debugee launches child processes and the debug adapter supports multi-session debugging, then each session's threads are shown separately. The currently active session is the one that is highlighted as the currently active thread/stack frame. To switch control to a different session, focus a thread within that session.

Note: This refers to sessions created as children of an existing session, and is not to be confused with [multiple (parent) debugging sessions][#multiple-debugging-sessions].

Program Output

In the outputs window, use the WinBar to select the output channel.
Alternatively, use :VimspectorShowOutput <category>. Use command-line completion to see the categories.
The debuggee prints to the stdout channel.
Other channels may be useful for debugging.

If the output window is closed, a new one can be opened with :VimspectorShowOutput <category> (use tab-completion - wildmenu to see the options).

Console

The console window is a prompt buffer, where that's available, and can be used as an interactive CLI for the debug adapter. Support for this varies amongst adapters.

Enter insert mode to enter a command to evaluate.
Alternatively, :VimspectorEval <expression>. Completion is available with some debug adapters.
Commit the request with <CR>
The request and subsequent result are printed.

NOTE: See also Watches above.

If the output window is closed, a new one can be opened with :VimspectorShowOutput Console.

Console autocompletion

The console prompt buffer has its omnifunc set to a function that will calculate completion for the current command/expression. This is trivially used with <Ctrl-x><Ctrl-o> (see :help ins-completion), or integrated with your favourite completion system. The filetype in the buffer is set to VimspectorPrompt.

For YouCompleteMe, the following config works well:

let g:ycm_semantic_triggers =  {
  \   'VimspectorPrompt': [ '.', '->', ':', '<' ]
}

Log View

The Vimspector log file contains a full trace of the communication between Vimspector and the debug adapter. This is the primary source of diagnostic information when something goes wrong that's not a Vim traceback.

If you just want to see the Vimspector log file, use :VimspectorToggleLog, which will tail it in a little window (doesn't work on Windows).

You can see some debugging info with :VimspectorDebugInfo

Closing debugger

To close the debugger, use:

Reset WinBar button
:VimspectorReset when the WinBar is not available.
call vimspector#Reset()

Terminate debuggee

If the debuggee is still running when stopping or resetting, then some debug adapters allow you to specify what should happen to it when finishing debugging. Typically, the default behaviour is sensible, and this is what happens most of the time. These are the defaults according to DAP:

If the request was 'launch': terminate the debuggee
If the request was 'attach': don't terminate the debuggee

Some debug adapters allow you to choose what to do when disconnecting. If you wish to control this behaviour, use :VimspectorReset or call vimspector#Reset( { 'interactive': v:true } ). If the debug adapter offers a choice as to whether or not to terminate the debuggee, you will be prompted to choose. The same applies for vimspector#Stop() which can take an argument: vimspector#Stop( { 'interactive': v:true } ).

Multiple debugging sessions

NOTE: This feature is experimental and any part of it may change in response to user feedback.

Vimspector supports starting an arbitrary number of debug sessions. Each session is associated with an individual UI tab. Typically, you only debug a single app and so don't need to think about this, but this advanced feature can be useful if you need to simultaneously debug multiple, independent applications, or multiple independent instances of your application.

At any time there is a single "active" root session. Breakpoints are associated with the current session, and all UI and API commands are applied to the currently active session.

When switching between root sessions, the breakpont signs for the previous session are removed and the breakpoints for the newly activated session are displayed. While it might be useful to see breakpoints for all sessions, this can be very confusing.

A typical workflow might be:

Start debugging a server app (e.g. :edit server.cc then <F5>). This starts a debug session named after the configuration selected. You could rename it :VimspectorRenameSession server.
Open the client code in a new tab (e.g. :tabedit client.cc)
Instantiate and make active a new debugging session and name it client: :VimspectorNewSession client (client is now the active session).
Add a breakpoint in the client session and start debugging with <F5>.

You now have 2 vimspector tabs. Intuitively, wwitching to a particular tab will make its session active. You can also manually switch the active session with :VimspectorSwitchToSession <name>.

So, in summary you have the following facilities:

VimspectorNewSession <name> This creates a new session and makes it active. Optional name is used in place of the generated one when starting a launch.
Switching to a specific debug tab makes that session active. This is intuitive and probably the most common way to work with this.
Switching manually using VimspectorSwitchToSession <tab complete>.
Name/Rename session with VimspectorRenameSession <new name>
Root-level sessions are never 'destroyed' but you can manually destroy them (if you're brave) using VimspectorDestroySession <name>. You can't destroy a running/active session.
vimspector#GetSessionName() useful for putting in a statusline. There's also vimspector#GetSessionID() for techies.

Here's an example of how you can display the current session name in the statusline (see :help statusline, or the documentation for your fancy status line plugin).

function! StlVimspectorSession()
  " Only include in buffers containing actual files
  if !empty( &buftype )
    return ''
  endif

  " Abort if vimspector not loaded
  if !exists( '*vimspector#GetSessionName' ) ||
        \ !exists( '*vimspector#GetSessionID' )
    return ''
  endif

  return vimspector#GetSessionName()
        \ .. ' ('
        \ .. vimspector#GetSessionID()
        \ .. ')'
endfunction

" ... existing statusline stuff
" set statusline=...
" Show the vimspector active session name (max 20 chars) if there is onw.
set statusline+=%(\ %.20{StlVimspectorSession()}\ %)

Debug profile configuration

For an introduction to the configuration of .vimspector.json, take a look at the Getting Started section of the Vimspector website.

For a full explanation, including how to use variables, substitutions and how to specify exception breakpoints, see the docs.

The JSON configuration file allows C-style comments:

// comment to end of line ...
/* inline comment ... */

Currently tested with the following debug adapters.

C, C++, Rust, etc.

vscode-cpptools
On macOS, I strongly recommend using CodeLLDB instead for C and C++ projects. It's really excellent, has fewer dependencies and doesn't open console apps in another Terminal window.

Example .vimspector.json (works with both vscode-cpptools and lldb-vscode. For lldb-vscode replace the name of the adapter with lldb-vscode:

vscode-cpptools Linux/MacOS:

{
  "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>"
      }
    }
    // ...
  }
}

vscode-cpptools Windows

NOTE FOR WINDOWS USERS: You need to install gdb.exe. I recommend using scoop install gdb. Vimspector cannot use the visual studio debugger due to licensing.

{
  "configurations": {
    "Launch": {
      "adapter": "vscode-cpptools",
      "filetypes": [ "cpp", "c", "objc", "rust" ], // optional
      "configuration": {
        "request": "launch",
        "program": "<path to binary>",
        "stopAtEntry": true
      }
    }
  }
}

Data visualization / pretty printing

Depending on the backend you need to enable pretty printing of complex types manually.

LLDB: Pretty printing is enabled by default
GDB: To enable gdb pretty printers, consider the snippet below. It is not enough to have set print pretty on in your .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
          }
        ]
      }
    }
  }
}

C++ Remote debugging

The cpptools documentation describes how to attach cpptools to gdbserver using miDebuggerAddress. Note that when doing this you should use the "request": "attach".

C++ Remote launch and attach

If you're feeling fancy, check out the reference guide for an example of getting Vimspector to remotely launch and attach.

CodeLLDB (MacOS)

CodeLLDB is superior to vscode-cpptools in a number of ways on macOS at least.

See Rust.

lldb-vscode (MacOS)

An alternative is to to use lldb-vscode, which comes with llvm. Here's how:

Install llvm (e.g. with HomeBrew: brew install llvm)
Create a file named /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

Rust is supported with any gdb/lldb-based debugger. So it works fine with vscode-cpptools and lldb-vscode above. However, support for rust is best in CodeLLDB.

./install_gadget.py --enable-rust or :VimspectorInstall CodeLLDB
Example: support/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}"
      }
    }
  }
}

Docs: https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md
NOTE: The CodeLLDB manual assumes you are using VSCode (sigh) and therefore says things which don't work in vimspector, as there is a whole load of javascript nonesense behind every VSCode plugin. I can't possibly document all the wierdnesses, but the following are known

To use the "custom" launch, you can't use "request": "custom" - this is invalid. Instead use "request": "launch", "custom": true. Because reasons
All the integration with cargo is done in the vscode javascript madness, so is not supported.
The stuff about remote agents uses "request": custom; see the point about "custom" launch above
Source Mapping (i.e., enabling step-into for standard library functions) can be done by adding "sourceMap": { "from_path" : "to_path" }. "from_path" can be found in disassembly window by going up in the stack trace; "to_path" is just your locally installed standard library path for current toolchain.

Jai

Jai debugging works fine with any of the other native debuggers. I recommend CodeLLDB, but cpptools also works.

Example:

{
  "$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

Python: debugpy
Install with install_gadget.py --enable-python or :VimspectorInstall debugpy, ideally requires a working compiler and the python development headers/libs to build a C python extension for performance.
NOTE: Debugpy no longer supports python 2. In order to continue to debug python 2 applications, use the debugpy-python2 adapter after installing the debugpy-python2 gadget.
Full options: 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>"
      }
    }
    ...
  }
}

Python Remote Debugging

In order to use remote debugging with debugpy, you have to connect Vimspector directly to the application that is being debugged. This is easy, but it's a little different from how we normally configure things. Specifically, you need to:

Start your application with debugpy, specifying the --listen argument. See the debugpy documentation for details.
Use the built-in "multi-session" adapter. This just asks for the host/port to connect to. For example:

{
  "configurations": {
    "Python Attach": {
      "adapter": "multi-session",
      "filetypes": [ "python" ], // optional
      "configuration": {
        "request": "attach",
        "pathMappings": [
          // mappings here (optional)
        ]
      }
    }
  }
}

See details of the launch configuration for explanation of things like pathMappings.

Additional documentation, including how to do this when the remote machine can only be contacted via SSH are provided by debugpy.

Python Remote launch and attach

If you're feeling fancy, checkout the reference guide for an example of getting Vimspector to remotely launch and attach.

Python 2

In order to continue to debug python 2 applications, ensure that you install the debugpy-python2 gadget (e.g. --force-enable-python2 or :VimspectorInstall debugpy-python2), and then change your configuration to use:

{
  "configurations": {
    "Python Attach": {
      "adapter": "debugpy-python2",
      // ...
    }
  }
}

for examk

TCL

TCL (TclProDebug)

See my fork of TclProDebug for instructions.

C♯

C# - dotnet core

Install with install_gadget.py --force-enable-csharp or :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": {}
      }
    }
  }
}

Go

Go (delve dap)

Requires:

install_gadget.py --enable-go or :VimspectorInstall delve
go 1.16 or later (YMMV on earlier versions)

This uses the DAP support built in to the delve debugger

{
  "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 Variables to configure the following:

dlvFlags: (string) additional command line arguments to pass to delve

The debugger (delve) is launched in a terminal window so that you can see its output and pass input to the debuggee.

See vscode-go docs for full launch options. Yes, it seems that's the only place they are documented (apparently, they are not documented by delve itself).

The vscode-go docs also have useful troubleshooting information

Go (legacy vscode-go)

Requires:

install_gadget.py --enable-go or :VimspectorInstall vscode-go
Delve installed, e.g. go get -u github.com/go-delve/delve/cmd/dlv
Delve to be in your PATH, or specify the dlvToolPath launch option

NOTE: Vimspector uses the "legacy" vscode-go debug adapter rather than the "built-in" DAP support in Delve. You can track #186 for that.

{
  "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" ]
      }
    }
  }
}

See the vscode-go docs for troubleshooting information

PHP

This uses the php-debug, see https://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug

Requires:

(optional) Xdebug helper for chrome https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc
install_gadget.py --force-enable-php or :VimspectorInstall vscode-php-debug
configured php xdebug extension
nodejs for vscode-php-debug

zend_extension=xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000

replace localhost with the ip of your workstation.

lazy alternative

zend_extension=xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_connect_back=true
xdebug.remote_port=9000

.vimspector.json

{
  "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
      }
    }
  }
}

Debug web application

append XDEBUG_SESSION_START=xdebug to your query string

curl "http://localhost?XDEBUG_SESSION_START=xdebug"

or use the previously mentioned Xdebug Helper extension (which sets a XDEBUG_SESSION cookie)

Debug cli application

export XDEBUG_CONFIG="idekey=xdebug"
php <path to script>

JavaScript, TypeScript, etc.

Node.js

Requires:

install_gadget.py --force-enable-node
Options described here: https://github.com/microsoft/vscode-js-debug/blob/main/OPTIONS.md
Example: support/test/node/simple, support/test/node/multiprocess

{
  "configurations": {
    "run": {
      "adapter": "js-debug",
      "filetypes": [ "javascript", "typescript" ], // optional
      "configuration": {
        "request": "launch",
        "stopOnEntry": true,
        "console": "integratedTerminal",
        "program": "${workspaceRoot}/simple.js",
        "cwd": "${workspaceRoot}",
        "type": "pwa-node" // this is the default, but see below
      }
    }
  }
}

vscode-js-debug supports a number of different "types" and can do some stuff that may or may not work. The type field is sadly not documented, but the valid values are defined here in the DebugType enum.

Vimspector has only been tested with pwa-node type.

Note also that for some reason this debug adapter always forces us to start multiple debug sessions. For a user, that shouldn't change anything (other than perhaps a slightly confusing stack trace). But it does make things more complicated and so there may be subtle bugs.

Node.js (legacy)

NOTE: This configuration uses the deprecated legacy debug adapter and will be removed in future. Please update your configurations to use the js-debug adapter. You may be able to just change the adapter name.

Requires:

install_gadget.py --force-enable-node
For installation, a Node.js environment that is < node 12. I believe this is an incompatibility with gulp. Advice, use nvm with nvm install --lts 10; nvm use --lts 10; ./install_gadget.py --force-enable-node ...
Options described here: https://code.visualstudio.com/docs/nodejs/nodejs-debugging
Example: support/test/node/simple

{
  "configurations": {
    "run": {
      "adapter": "vscode-node",
      "filetypes": [ "javascript", "typescript" ], // optional
      "configuration": {
        "request": "launch",
        "protocol": "auto",
        "stopOnEntry": true,
        "console": "integratedTerminal",
        "program": "${workspaceRoot}/simple.js",
        "cwd": "${workspaceRoot}"
      }
    }
  }
}

Chrome/Firefox

This uses the chrome/firefox debugger (they are very similar), see https://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome and https://marketplace.visualstudio.com/items?itemName=firefox-devtools.vscode-firefox-debug, respectively.

It allows you to debug scripts running inside chrome from within Vim.

./install_gadget.py --force-enable-chrome or :VimspectorInstall debugger-for-chrome
./install_gadget.py --force-enable-firefox or :VimspectorInstall debugger-for-firefox
Example: support/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
      }
    }
  }
}

Java

Vimspector works well with the java debug server, which runs as a jdt.ls (Java Language Server) plugin, rather than a standalone debug adapter.

Vimspector is not in the business of running language servers, only debug adapters, so this means that you need a compatible Language Server Protocol editor plugin to use Java. I recommend YouCompleteMe, which has full support for jdt.ls, and most importantly a trivial way to load the debug adapter and to use it with Vimspector.

Hot code replace

When using the java debug server, Vimspector supports the hot code replace custom feature. By default, when the underlying class files change, vimspector asks the user if they wish to reload these classes at runtime.

This behaviour can be customised:

let g:vimspector_java_hotcodereplace_mode = 'ask' - the default, ask the user for each reload.
let g:vimspector_java_hotcodereplace_mode = 'always' - don't ask, always reload
let g:vimspector_java_hotcodereplace_mode = 'never' - don't ask, never reload

Usage with YouCompleteMe

Set up YCM for java.
Get Vimspector to download the java debug plugin: install_gadget.py --force-enable-java <other options...> or :VimspectorInstall java-debug-adapter
Configure Vimspector for your project using the vscode-java adapter, e.g.:

{
  "configurations": {
    "Java Attach": {
      "adapter": "vscode-java",
      "filetypes": [ "java" ],
      "configuration": {
        "request": "attach",
        "hostName": "${host}",
        "port": "${port}",
        "sourcePaths": [
          "${workspaceRoot}/src/main/java",
          "${workspaceRoot}/src/test/java"
        ]
      }
    }
  }
}

Tell YCM to load the debugger plugin. This should be the gadgets/<os> directory, not any specific adapter. e.g. in .vimrc

" Tell YCM where to find the plugin. Add to any existing values.
let g:ycm_java_jdtls_extension_path = [
  \ '</path/to/Vimspector/gadgets/<os>'
  \ ]

Create a mapping, such as <leader><F5> to start the debug server and launch vimspector, e.g. in ~/.vim/ftplugin/java.vim:

let s:jdt_ls_debugger_port = 0
function! s:StartDebugging()
  if s:jdt_ls_debugger_port <= 0
    " Get the DAP port
    let s:jdt_ls_debugger_port = youcompleteme#GetCommandResponse(
      \ 'ExecuteCommand',
      \ 'vscode.java.startDebugSession' )

    if s:jdt_ls_debugger_port == ''
       echom "Unable to get DAP port - is JDT.LS initialized?"
       let s:jdt_ls_debugger_port = 0
       return
     endif
  endif

  " Start debugging with the DAP port
  call vimspector#LaunchWithSettings( { 'DAPPort': s:jdt_ls_debugger_port } )
endfunction

nnoremap <silent> <buffer> <Leader><F5> :call <SID>StartDebugging()<CR>

You can then use <Leader><F5> to start debugging rather than just <F5>.

If you see "Unable to get DAP port - is JDT.LS initialized?", try running :YcmCompleter ExecuteCommand vscode.java.startDebugSession and note the output. If you see an error like ResponseFailedException: Request failed: -32601: No delegateCommandHandler for vscode.java.startDebugSession, make sure that:

Your YCM jdt.ls is actually working, see the YCM docs for troubleshooting
The YCM jdt.ls has had time to initialize before you start the debugger
That g:ycm_java_jdtls_extension_path is set in .vimrc or prior to YCM starting

For the launch arguments, see the vscode document.

Other LSP clients

See this issue for more background.

Lua

Lua is supported through local-lua-debugger-vscode. This debugger uses stdio to communicate with the running process, so calls to io.read will cause problems.

./install_gadget.py --enable-lua or :VimspectorInstall local-lua-debugger-vscode
Examples: support/test/lua/simple and 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}"]
      }
    }
  }
}

Other servers

Java - vscode-javac. This works, but is not as functional as Java Debug Server. Take a look at this comment for instructions.

See also the wiki which has community-contributed plugin files for some languages.

Customisation

There is very limited support for customisation of the UI.

Changing the default signs

Vimsector uses the following signs internally. If they are defined before Vimsector uses them, they will not be replaced. So to customise the signs, define them in your vimrc.

Sign	Description	Priority
`vimspectorBP`	Line breakpoint	9
`vimspectorBPCond`	Conditional line breakpoint	9
`vimspectorBPLog`	Logpoint	9
`vimspectorBPDisabled`	Disabled breakpoint	9
`vimspectorPC`	Program counter (i.e. current line)	200
`vimspectorPCBP`	Program counter and breakpoint	200
`vimspectorNonActivePC`	Program counter for non-focused thread	9
`vimspectorCurrentThread`	Focussed thread in stack trace view	200
`vimspectorCurrentFrame`	Current stack frame in stack trace view	200

The default symbols are the equivalent of something like the following:

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

If the signs don't display properly, your font probably doesn't contain these glyphs. You can easily change them by defining the sign in your vimrc. For example, you could put this in your vimrc to use some simple ASCII symbols:

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

Sign priority

Many different plugins provide signs for various purposes. Examples include diagnostic signs for code errors, etc. Vim provides only a single priority to determine which sign should be displayed when multiple signs are placed at a single line. If you are finding that other signs are interfering with vimspector's (or vice-versa), you can customise the priority used by vimspector by setting the following dictionary:

let g:vimspector_sign_priority = {
  \   '<sign-name>': <priority>,
  \ }

For example:

let g:vimspector_sign_priority = {
  \    'vimspectorBP':          3,
  \    'vimspectorBPCond':      3,
  \    'vimspectorBPLog':       3,
  \    'vimspectorBPDisabled':  3,
  \    'vimspectorNonActivePC': 3,
  \    'vimspectorPC':          999,
  \    'vimspectorPCBP':        999,
  \ }

All keys are optional. If a sign is not customised, the default priority it used (as shown above).

See :help sign-priority. The default priority is 10, larger numbers override smaller ones.

NOTE: The default vimspectorNonActivePC sign does not add any text to the sign column, it simply adds a line highlight so that you can see the lines where other threads or processes are currently stopped. As a result this sign normally should merge with any sign that adds a symbol (such as a breakpoint sign). Vim will only merge the properties of signs with the same priority, so if changing the default priorities, it's recommended that:

All the breakpoint signs (vimspectorBP, vimspectorBPCond, etc.) have the same priority.
You also set the vimspectorNonActivePC sign that same priority
Active PC ( vimspectorPC, vimspectorPCBP, etc.) have a higher priority.

Presentation Hints

NOTE: This customisation point is currently unsable and may change at any time.

Sometimes the Debug Adapter provides hints as to how the UI should display certain things. This includes stack frames, variables etc.

Vimspector provides a simple way to customise how these are displayed, by setting values in the dictionary g:vimsepctor_presentation_hint_hl.

The following keys are supported with the mentioned default highlight group.

Group	Key	Usage	Default
all	`normal`	anything not covered below	`Normal`
Stack trace	`emphasize`	emphasize sources in stack trace	`Title`
Stack trace	`deemphasize`	deemphasize sources in stack trace	`Conceal`
Stack trace	`label`	stack frames which are "labels", not representing actual frames	`NonText`
Stack trace	`subtle`	stack frames which are internal or not interesting	`Conceal`
Scopes	`arguments`	Function arguments scope	`Title`
Scopes	`locals`	Local variables scope	`Title`
Scopes	`registers`	Registers scope	`Title`
Variables	`property`	Function arguments scope	`Identifier`
Variables	`method`	Local variables scope	`Function`
Variables	`class`	Registers scope	`Type`
Variables	`data`	Registers scope	`String`

In addition, any value supplied in the DAP VariablePresentationHint can be set which will be used if supplied by the debug adapter.

A silly example; the defaults should probably be OK for most colour scehemes:

let g:vimspector_presentation_hint_hl = {
  \    'normal': 'Identifier',
  \    'label':  'Title',
  \ }

Changing the default window sizes

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 following options control the default sizes of the UI windows (all of them are numbers)

g:vimspector_sidebar_width (default: 50 columns): The width in columns of the left utility windows (variables, watches, stack trace)
g:vimspector_bottombar_height (default 10 lines): The height in rows of the output window below the code window.

Example:

let g:vimspector_sidebar_width = 75
let g:vimspector_bottombar_height = 15

Changing the terminal size

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.

Example:

let g:vimspector_code_minwidth = 90
let g:vimspector_terminal_maxwidth = 75
let g:vimspector_terminal_minwidth = 20

Custom mappings while debugging

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.

Pre-launch building strategies

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.

Disabling the WinBar

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=0

The WinBar is in any case not displayed if the mouse is not enabled.

Advanced UI customisation

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:

Hide a particular window or windows
Move a particular window or windows
Resize windows
Have multiple windows for a particular buffer (say, you want 2 watch windows)
etc.

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 session
VimspectorTerminalOpened: 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 session
g: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

Customising the WinBar

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

Example

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

FAQ

Q: Does it work with this language? A: Probably, but it won't necessarily be easy to work out what to put in the .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
How do I stop it starting a new Terminal.app on macOS? See this comment
Can I specify answers to the annoying questions about exception breakpoints in my .vimspector.json ? Yes, see here.
Do I have to specify the file to execute in .vimspector.json, or could it be the current vim file? You don't need to. You can specify $file for the current active file. See here for complete list of replacements in the configuration file.
You allow comments in .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 Comment

What is the difference between a gadget 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.
The signs and winbar display funny symbols. How do I fix them? See this and this
What's this telemetry stuff all about? Are you sending my data to evil companies? Debug adapters (for some reason) send telemetry data to clients. Vimspector simply displays this information in the output window. It does not and will not ever collect, use, forward or otherwise share any data with any third parties.
Do I have to put a .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 lot
I'm confused about remote debugging configuration, can you explain it? eh... kind of. Reference: https://puremourning.github.io/vimspector/configuration.html#remote-debugging-support. Some explanations here too: #478 (comment)
I'm trying to debug a Django (django?) project and it's not working. Can you help? sure, check this link which has a working example. Or google it.
Can vimspector build my code before debugging it? Can I deploy it to a remote host before debugging it? No, not really. Vimspector is just a debugger, not a task system or build automation system - there are other tools for that. There is however a hack you can use - you can use a 'shell' variable to execute a command and just discard the output. Other options are discussed in this issue
It's annoying to manually type in the PID when attaching. Do you have a PID picker? There's no PID picker in vimspector at the moment, but you could write something and wrap vimspector#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: #{ extends: '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": ""
      \     }
      \   }
      \ } }

vimspector's People

Contributors

Stargazers

Watchers

Forkers

arwtyxouymz gitter-badger ousttrue adelarsq romgrk chetgurevitch mathijs-bakker tinmarino panders23 trendingtechnology axrt deresmos danilbykov ylpiao-7276 superctr fromasmtodisasm milind-shakya-sp lusu2004 neiljohari garyeung moetayuko pchaos cpypro saraedum eyalk5 yukinjie esetnik ayyess awwalker kceiw chinnkarahoi vitbomm joalon benliepert yanganto roachsinai waynebowie99 sandwind chenlihui0223 luoxz-ai unknownfx02 orochi4268 eyalz800 kgonidis ayberkydn camilo-schoeningh-sociomantic al-hub tapo4eg3d sharksforarms eduardomezencio dsych felixfeit andwilley common-forks littlejohnkhan yatli cposture badbyte7 aw3i allanguigou lelutin eggnita ijustwanthaveaname cainiao329 przepompownia eric97 jinlixian ygorsouza jez pixb cosminadrianpopescu qmiinh aqez leytzher opensofttools mareq lf- satrac docnoe eshad bigpoliceman vijaykm01 tizee imaninja187 jerrywee008 doanngochoanghy qingwei8 runwu2012 sherlockhomles esmool yhao21 sgoth jyapayne sheerun smalinux junfff jpfeiffer16 mflova n-0 archibate

vimspector's Issues

[Feature Request]: Don't open a new terminal window after every restart

I'm sorry for the issues bombard, I was just thinking that these are different topics to discuss so I didn't want to put them all in one big issue.

So today, after some debug sessions with vimspector, I noticed that the stdout/stderr window of my running program is being recreated every time I start a debug session. I must say that it's kind of annoying to quit the old window every time a new session is started. I'm also a Neovim refugee because of #30 and so I'm not used yet to Vim's :terminals which makes this process a little bit harder for me TBH..

Are you willing to accept donations?

If so, it would be good to put a link at the README, just a suggestion 😄

[Feature Request]: support for Windows

Vim is supporting windows, as well as the dap and python3.
So why windows is not supported? Is it possiable?

lldb-vscode - DAP tool for lldb

You mentioned DAP in the background section so I figured I'd give you a heads up that an official lldb DAP adapter was released a couple weeks ago on master - https://github.com/llvm-mirror/lldb/tree/master/tools/lldb-vscode.

Question: Where does the python adapter look for python libraries?

I'm using Direnv to manage my environment for every project I'm working on. Using some other tools in between, when entering a Python project's directory, direnv adds to my $PATH a bin directory with a special python executable. This /somewhere/bin/python is a shell wrapper that sets PYTHONPATH according to the libraries I told direnv to load. When I use this python, I can import all the libraries I told direnv to load to the environment.

I'm using NixOS and Neovim and I'm trying to figure out the nature of the following error:

Traceback (most recent call last):
  File "/nix/store/6grpqfvag3ysrd1ficsrips8afzmv9wi-python3-3.9.0a3/lib/python3.9/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/nix/store/6grpqfvag3ysrd1ficsrips8afzmv9wi-python3-3.9.0a3/lib/python3.9/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/doron/.config/nvim/pack/functional/start/vimspector/gadgets/linux/debugpy/build/lib/debugpy/__main__.py", line 45, in <module>
    cli.main()
  File "/home/doron/.config/nvim/pack/functional/start/vimspector/gadgets/linux/debugpy/build/lib/debugpy/../debugpy/server/cli.py", line 361, in main
    run()
  File "/home/doron/.config/nvim/pack/functional/start/vimspector/gadgets/linux/debugpy/build/lib/debugpy/../debugpy/server/cli.py", line 203, in run_file
    runpy.run_path(options.target, run_name="__main__")
  File "/nix/store/6grpqfvag3ysrd1ficsrips8afzmv9wi-python3-3.9.0a3/lib/python3.9/runpy.py", line 263, in run_path
    return _run_module_code(code, init_globals, run_name,
  File "/nix/store/6grpqfvag3ysrd1ficsrips8afzmv9wi-python3-3.9.0a3/lib/python3.9/runpy.py", line 96, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "/nix/store/6grpqfvag3ysrd1ficsrips8afzmv9wi-python3-3.9.0a3/lib/python3.9/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/var/src/beets/beet", line 20, in <module>
    import beets.ui
  File "/var/src/beets/beets/__init__.py", line 20, in <module>
    from beets.util import confit
  File "/var/src/beets/beets/util/__init__.py", line 34, in <module>
    import six
ModuleNotFoundError: No module named 'six'

[Process exited 1]

six is a module that's loaded into the project's environment, but it wasn't present when I installed the adapter. Hence It seems that this has to do something with my setup so I'm not formatting this issue as a bug.

My suspicion is that the python interpreter that used to install the debugpy adapter is the same interpreter that launches the debug session. And that's why dependencies available in my current $PATH's python aren't available to the adapter.

[Feature Request]: Access to the underlying debugger

Is it possible to have write access to the underlying debugger console when possible? i.e gdb

[neovim] AttributeError: 'LegacyVim' object has no attribute 'bindeval'

Not sure if it's a goal of yours to support neovim but the bindeval at python3/vimspector/debug_session.py:349 crashes vimspector on neovim since it doesn't support that API.

Install chrome debugger

Describe the bug
When running install_gadget script with option --force-enable-chrome. Script print install_gadget.py: error: unrecognized arguments: --force-enable-chrome.

To Reproduce
Run install_gadget script with option --force-enable-chrome.

Vimspector config file:

{
  "adapters": {
      "lldb-mi": {
        "name": "lldb-mi",
        "command": [
          "node",
          "$HOME/.vscode/extensions/webfreak.debug-0.22.0/out/src/lldb.js"
        ]
      },
      "cppdbg": {
        "name": "cppdbg",
        "command": [ "$HOME/.vscode/extensions/ms-vscode.cpptools-0.20.1/debugAdapters/OpenDebugAD7" ],
        "attach": {
          "pidProperty": "processId",
          "pidSelect": "ask"
        }
      },
      "python": {
        "name": "python",
        "command": [
          "node",
          "$HOME/.vscode/extensions/ms-python.python-2018.4.0/out/client/debugger/Main.js"
        ]
      },
      "bashdb": {
        "name": "bashdb",
        "command": [
          "node",
          "$HOME/.vscode/extensions/rogalmic.bash-debug-0.2.0/out/bashDebug.js"
        ]
      },
      "lldb": {
        "name": "lldb",
        "command": [
          "lldb",
          "-b",
          "-O",
          "command script import '$HOME/.vscode/extensions/vadimcn.vscode-lldb-0.8.7/adapter'",
          "-O",
          "script adapter.main.run_stdio_session()"
        ]
      }
  },
  "configurations": {
    "simple_c_program - lldb-mi Launch": {
      "adapter": "lldb-mi",
      "configuration": {
        "request": "launch",
        "target": "support/test/cpp/simple_c_program/test",
        "args": [],
        "cwd": ".",
        "lldbmipath": "$HOME/.vscode/extensions/ms-vscode.cpptools-0.20.1/debugAdapters/lldb/bin/lldb-mi",
        "trace": true,
        "logFilePath": "$HOME/.vimspector.protocol.log"
      }
    },
    "simple_c_progra - ms Launch": {
      "adapter": "cppdbg",
      "configuration": {
        "name": "ms Launch",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/support/test/cpp/simple_c_program/test",
        "args": [],
        "cwd": "$HOME",
        "environment": [],
        "externalConsole": true,
        "MIMode": "lldb"
      }
    },
    "simple_python - launch": {
      "adapter": "python",
      "configuration": {
        "name": "Python: Current File",
        "type": "python",
        "request": "launch",
        "cwd": "${workspaceRoot}/support/test/python/simple_python",
        "stopOnEntry": true,
        "console": "externalTerminal",
        "debugOptions": [],
        "program": "${workspaceRoot}/support/test/python/simple_python/main.py"
      }
    },
    "simple_c_program - MS Attach": {
      "adapter": "cppdbg",
      "configuration": {
        "name": "(lldb) Attach",
        "type": "cppdbg",
        "request": "attach",
        "program": "${workspaceRoot}/support/test/cpp/simple_c_program/test",
        "MIMode": "lldb"
      }
    },
    "bashdb": {
      "adapter": "bashdb",
      "configuration": {
        "type": "bashdb",
        "request": "launch",
        "name": "Bash-Debug (simplest configuration)",
        "program": "$HOME/.vim/bundle/YouCompleteMe/install.sh",
        "args": [],
        "cwd": "$HOME/.vim/bundle/YouCompleteMe",
        "pathBash": "bash",
        "pathBashdb": "bashdb",
        "pathCat": "cat",
        "pathMkfifo": "mkfifo",
        "pathPkill": "pkill",
        "showDebugOutput": true,
        "trace": true
      }
    },
    "lldb launch": {
      "adapter": "lldb",
      "configuration": {
        "type": "lldb",
        "request": "launch",
        "name": "LLDB: Launch",
        "program": "$HOME/Development/vim/src/vim",
        "args": [],
        "cwd": "$HOME/Development/vim"
      }
    },
    "racerd": {
      "adapter": "lldb",
      "configuration": {
        "type": "lldb",
        "request": "launch",
        "name": "LLDB: Launch",
        "program": "$HOME/.vim/bundle/YouCompleteMe/third_party/ycmd/third_party/racerd/target/debug/racerd",
        "args": [
          "serve",
          "--port=12345",
          "--secret-file=secretfile"
        ],
        "cwd": "$HOME/.vim/bundle/YouCompleteMe/third_party/ycmd"
      }
    }
  }
}

Expected behavior
I would expect the script to install the chrome debugger gadget

Actual behaviour

OS = linux
gadget_dir = /home/quentin/.vim/pack/default/start/vimspector/gadgets/linux
usage: install_gadget.py [-h] [--all] [--force-all] [--enable-c] [--disable-c]
                         [--enable-python] [--disable-python] [--enable-tcl]
                         [--disable-tcl] [--force-enable-csharp]
                         [--enable-bash] [--disable-bash] [--enable-go]
                         [--disable-go] [--force-enable-node]
                         [--force-enable-typescript]
install_gadget.py: error: unrecognized arguments: --force-enable-chrome

Environemnt

Output of vim --version

VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 29 2019 22:27:49)
Included patches: 1-2102
Compiled by Arch Linux
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_any_white
+arabic            +file_in_path      +mouse_urxvt       +tcl/dyn
+autocmd           +find_in_path      +mouse_xterm       +termguicolors
+autochdir         +float             +multi_byte        +terminal
-autoservername    +folding           +multi_lang        +terminfo
+balloon_eval      -footer            -mzscheme          +termresponse
+balloon_eval_term +fork()            +netbeans_intg     +textobjects
+browse            +gettext           +num64             +textprop
++builtin_terms    -hangul_input      +packages          +timers
+byte_offset       +iconv             +path_extra        +title
+channel           +insert_expand     +perl/dyn          +toolbar
+cindent           +job               +persistent_undo   +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           +python/dyn        +visual
+cmdline_info      +libcall           +python3/dyn       +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          +ruby/dyn          +wildmenu
+cursorbind        +lua/dyn           +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con_gui    +mksession         +smartindent       +X11
+diff              +modify_fname      +sound             -xfontset
+digraphs          +mouse             +spell             +xim
+dnd               +mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        +xsmp_interact
+emacs_tags        +mouse_gpm         -sun_workshop      +xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary        
+extra_search      +mouse_sgr         -tag_old_static    
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/libdrm -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread  -D_FORTIFY_SOURCE=2  -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_REENTRANT  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf -lnsl    -lcanberra  -lacl -lattr -lgpm -ldl   -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/perl5/5.30/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc   -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm

Output of which vim:

/usr/bin/vim

Output of :py3 pass:

paste here

Operating system: linux 5.3

Additional context
I fixed the problem by using the --force-enable-typescript.

Then i got an error saying that the downloaded content wasn't a tar archive.

I fixed the problem by changing the url of the typescript gadget.

Know my .gadgets.json looks like this :

{
  "adapters": {
    "chrome": {
      "command": [
        "node",
        "${gadgetDir}/debugger-for-chrome/out/src/chromeDebug.js"
      ],
      "name": "debugger-for-chrome",
      "type": "chrome"
    }
  }
}

And the debugger doesn't launch without any errors.

After taking a look a the extracted archive i found that chromeDebug.js doesn't exist, instead there is a chromeDebug.ts file.

I suppose that i must compile those typescript files to js with tsc/

Go support via Delve

If you will excuse me not completing the template, this is a rather more vague request for information

In a tools session at GopherCon 2019 (notes) there was an interesting discussion started about Delve and the Debugger Adapter Protocol. Delve has become the de facto debugger for Go, and it looks like it will be blessed as the official debugger by the Go team.

As part of trying to understand how Delve can become better integrated in various editors, the Debugger Adapter Protocol was brought up. Delve does not currently speak this protocol, but if there is sufficient support the work could be done (relatively easily).

I've previously seen this project, but it was this discussion that prompted me to raise an issue:

what are your thoughts/experience of the Debugger Adapter Protocol?
do you have any advice on how to proceed on the question of how to integrate Delve with Vim (and other editors)
...

The context of considering the Debugger Adapter Protocol is the Go now has an official LSP server, gopls. Hence, building on that success, it seems logical to consider the Debugger Adapter Protocol.

Thanks in advance

Offsets should be UTF-16 code units

Describe the bug

The DAP uses utf-16 code units for offsets (ref: microsoft/debug-adapter-protocol#91).

Vimspector uses probably a mix of byte offsets and unicode codepoints.

To Reproduce

Add a line with a multi-byte character and a language (like TCL) that provides the column offset.

Expected behavior

Offsets are interpreted correctly according to the appropriate notion of "characters"

Actual behaviour

Not sure yet, i haven't tried it, but i expect tracebacks

No information displayed with naive rust lldb adapter try.

Describe the bug
I keep wandering through the docs at vimspector and vscode, and I find no way properly set up Rust debugging with lldb properly. Should I use rust-lldb? How?

To Reproduce
Create dummy rust project, here:
Cargo.toml

[package]
name = "rust_test"
version = "0.1.0"
authors = ["Iago-lito"]
edition = "2018"

[[bin]]
name = "main"
path = "src/main.rs"

src/main.rs

fn main() {
    let a = 5;
    let mut b = 3;

    meth(&mut b, &a);
    println!("{}", a);
    println!("{}", b);
}

fn meth(b: &mut i32, a: &i32) -> bool {
    let inner = 7;
    println!("Inside.");
    *b += a + inner;
    return true;
}

Try configuring a naive .vimspector.json

{
    "adapters": {
        "lldb": {
            "name": "lldb",
            "command": [
                "lldb",
                "-b",
                "-O",
                "command script import '$HOME/.vscode-oss/extensions/vadimcn.vscode-lldb-1.4.5/adapter'",
                "-O",
                "script adapter.main.run_stdio_session()"
            ]
        }
    },
    "configurations": {
        "simple_rust - launch": {
            "adapter": "lldb",
            "configuration": {
                "name": "LLDB: Launch",
                "type": "llbd",
                "request": "launch",
                "cwd": "${workspaceRoot}",
                "args": [],
                "program": "${workspaceRoot}/target/debug/main"
            }
        }
    }
}

Set up a breakpoint inside meth(), then :call vimspector#Launch().

Expected behavior
5 windows open in a new tab, with debugging information.

Actual behaviour
The windows are mostly empty. The interpreter trivially evaluates any <random-input> to <random-input> like a schoolcase echo server. The stacktrace seems to work, but the "Scopes" are empty, and there are no "Variables" listed in corresponding window :(

.vimspector.log

Environment

$ uname -a
Linux etak 5.5.2-arch1-1 #1 SMP PREEMPT Tue, 04 Feb 2020 18:56:18 +0000 x86_64 GNU/Linux

$ nvim --version
NVIM v0.5.0-374-gd9657b3ae
Build type: RelWithDebInfo
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/iago-lito/.cache/yay/neovim-git/src/neovim-git/build/config -I/home/iago-lito/.cache/yay/neovim-git/src/neovim-git/src -I/usr/include -I/home/iago-lito/.cache/yay/neovim-git/src/neovim-git/build/src/nvim/auto -I/home/iago-lito/.cache/yay/neovim-git/src/neovim-git/build/include
Compilé par iago-lito@etak

Features: +acl +iconv +tui
See ":help feature-compile"

         fichier vimrc système : "$VIM/sysinit.vim"
               $VIM par défaut : "/usr/share/nvim"

Run :checkhealth for more info

$ git rev-parse HEAD
79df51e83c8775f34fcf5c225f0c5c152d52094e

$ which vim 
vim: aliased to nvim -p

$ which nvim
/usr/bin/nvim

:py3 pass and :py3 import vim yield nothing.

:checkhealth
health#coc#check
========================================================================
  - OK: Environment check passed

  - OK: Javascript bundle found
  - OK: Service started

health#nvim#check
========================================================================
## Configuration
  - OK: no issues found

## Performance
  - OK: Build type: RelWithDebInfo

## Remote Plugins
  - OK: Up to date

## terminal
  - INFO: key_backspace (kbs) terminfo entry: key_backspace=^H
  - INFO: key_dc (kdch1) terminfo entry: key_dc=\E[3~
  - INFO: $VTE_VERSION='5803'
  - INFO: $COLORTERM='truecolor'

health#provider#check
========================================================================
## Clipboard (optional)
  - OK: Clipboard tool found: xclip

## Python 2 provider (optional)
  - INFO: `g:python_host_prog` is not set.  Searching for python2 in the environment.
  - INFO: Executable: /usr/bin/python2
  - INFO: Python version: 2.7.17
  - INFO: pynvim version: 0.3.2 (outdated; from /usr/lib/python2.7/site-packages/neovim)
  - WARNING: Latest pynvim is NOT installed: 0.4.1

## Python 3 provider (optional)
  - INFO: `g:python3_host_prog` is not set.  Searching for python3 in the environment.
  - INFO: Executable: /usr/bin/python3
  - INFO: Python version: 3.8.1
  - INFO: pynvim version: 0.4.1
  - OK: Latest pynvim is installed.

## Python virtualenv
  - OK: no $VIRTUAL_ENV

## Ruby provider (optional)
  - INFO: Ruby: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [x86_64-linux]
  - WARNING: `neovim-ruby-host` not found.
    - ADVICE:
      - Run `gem install neovim` to ensure the neovim RubyGem is installed.
      - Run `gem environment` to ensure the gem bin directory is in $PATH.
      - If you are using rvm/rbenv/chruby, try "rehashing".
      - See :help |g:ruby_host_prog| for non-standard gem installations.

## Node.js provider (optional)
  - INFO: Node.js: v10.18.1
  - WARNING: Missing "neovim" npm (or yarn) package.
    - ADVICE:
      - Run in shell: npm install -g neovim
      - Run in shell (if you use yarn): yarn global add neovim

## Perl provider (optional)
  - WARNING: `perl` and `cpanm` must be in $PATH.
    - ADVICE:
      - Install Perl and cpanminus and verify that `perl` and `cpanm` commands work.

I am very excited to see DAP interacting with Vim, thank you for this huge work. And thank you for support :)

[Bug report]: Please make it simple to setup

Is your feature request related to a problem? Please describe.
Hi. I'm not sure is it a bug report or feature request! But let me first thank you for neovim support. I'm so glad to see that PR merged eventually. :)

I read README file and these instructions for setting up vimspector.

But after reading some lines, let me confess: I got confused!
First, please update README and that page, becuase there are some differences for setting up in vim vs neovim. For example here:

Untar the release tarball for your OS into $HOME/.vim/pack:

I downloaded latest release tarball and i don't have any idea where should i put it and what should i do after that! Actually you said:

Configure your project's debug profiles (create .vimspector.json)

But i don't have any idea how do that.

Please, please make the installation process easier.

[Feature Request]: Vim documentation

Is your feature request related to a problem? Please describe.

:help vimspector should show the usage and configuration documentation.

Describe the solution you'd like

Ideally share some documentation with the website of the readme (like ycm).

Describe alternatives you've considered
Put a url linkt to the website. just a simple overview and link. etc.

[Feature Request]: Open current file in code view when starting a debug session

Is your feature request related to a problem? Please describe.
When I start a new debug session, the code window is empty, and I have to open my current source file manually. Most of the time, when I attach or launch the debugger session, I want to set a breakpoint in the file I have open right now.

Describe the solution you'd like
If I start a debugging session, the code window should automatically open my current file in the original tab.

Describe alternatives you've considered
Maybe it is configurable if it starts empty or with the current file?

Additional context

Request: some clarity for all the types of "names"

I set up lldb-vscode via copy and pasting the config you have on the front readme. It lists an adapter named...? "lldb-vscode". It has a property called "name" with a value of "lldb". It's in a file named lldb-vscode.json.

I copy and paste the .vimspector.json you have for it. It has a <name>, an "adapter" key whose value seems to be some sort of "name", a configuration with a "name" : "" and a "type" which refers to an adapter name.

I haven't been able to get vimspector to launch or attach to anything yet and I can't tell what the problem is so far. But my first approach has been musical chairs with all the permutations of the word "name" and I'm not sure I've gotten it right yet.

[Feature Request]: Set variable value, etc.

DAP supports assigning values to variables/expressions.

Vimspector does not.

install_gadget.py fails for nodejs

I don't have time to submit a full nice bug report, but just thought I would throw this out there so it is at least mildly documented. When installing the node gadget, it fails on submodule initialisation.

As a work around I commented out lines 503-508 in install_gadget.py, and ran it again. Running the submodule commands in those repos returned exit code 0, and didn't appear to do anything.

I can update with more details tomorrow if needed.

.vim λ python ~/.vim/plugged/vimspector/install_gadget.py --force-enable-node
OS = linux
gadget_dir = /home/owg1/.vim/plugged/vimspector/gadgets/linux
Cloning into '/home/owg1/.vim/plugged/vimspector/gadgets/linux/download/vscode-node-debug2'...
remote: Enumerating objects: 169, done.
remote: Counting objects: 100% (169/169), done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 4507 (delta 105), reused 104 (delta 54), pack-reused 4338
Receiving objects: 100% (4507/4507), 1.50 MiB | 3.29 MiB/s, done.
Resolving deltas: 100% (2842/2842), done.
Note: switching to 'v1.39.1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at cc55960 1.39.1
fatal: not a git repository (or any of the parent directories): .git
Traceback (most recent call last):
  File "/home/owg1/.vim/plugged/vimspector/install_gadget.py", line 605, in <module>
    CloneRepoTo( url, ref, destination )
  File "/home/owg1/.vim/plugged/vimspector/install_gadget.py", line 503, in CloneRepoTo
    subprocess.check_call( [ 'git', 'submodule', 'sync', '--recursive' ] )
  File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['git', 'submodule', 'sync', '--recursive']' returned non-zero exit status 128.
FAILED installing vscode-node-debug2: Command '['git', 'submodule', 'sync', '--recursive']' returned non-zero exit status 128.
Traceback (most recent call last):
  File "/home/owg1/.vim/plugged/vimspector/install_gadget.py", line 637, in <module>
    raise RuntimeError( 'Failed to install gadgets: {}'.format(
RuntimeError: Failed to install gadgets: vscode-node-debug2
.vim λ ls /home/owg1/.vim/plugged/vimspector/gadgets/linux/download/vscode-node-debug2
total 352K
drwxr-xr-x 12 owg1 owg1 4,0K  9 jan 16.52 .
drwxr-xr-x  3 owg1 owg1 4,0K  9 jan 16.52 ..
drwxr-xr-x  8 owg1 owg1 4,0K  9 jan 16.52 .git
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 .github
drwxr-xr-x 16 owg1 owg1 4,0K  9 jan 16.52 i18n
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 images
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 msbuild
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 src
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 test
drwxr-xr-x 27 owg1 owg1 4,0K  9 jan 16.52 testdata
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 .vscode
drwxr-xr-x  2 owg1 owg1 4,0K  9 jan 16.52 .vsts
-rw-r--r--  1 owg1 owg1  333  9 jan 16.52 CODE_OF_CONDUCT.md
-rw-r--r--  1 owg1 owg1  960  9 jan 16.52 CONTRIBUTING.md
-rw-r--r--  1 owg1 owg1  170  9 jan 16.52 .gitignore
-rw-r--r--  1 owg1 owg1 6,2K  9 jan 16.52 gulpfile.js
-rw-r--r--  1 owg1 owg1 1,2K  9 jan 16.52 LICENSE.txt
-rw-r--r--  1 owg1 owg1  17K  9 jan 16.52 package.json
-rw-r--r--  1 owg1 owg1 230K  9 jan 16.52 package-lock.json
-rw-r--r--  1 owg1 owg1 4,4K  9 jan 16.52 package.nls.json
-rw-r--r--  1 owg1 owg1  906  9 jan 16.52 README.md
-rw-r--r--  1 owg1 owg1 1,5K  9 jan 16.52 ThirdPartyNotices.txt
-rw-r--r--  1 owg1 owg1  464  9 jan 16.52 tsconfig.json
-rw-r--r--  1 owg1 owg1 2,0K  9 jan 16.52 tslint.json
-rw-r--r--  1 owg1 owg1  813  9 jan 16.52 .vscodeignore
.vim λ

[Feature Request]: Why so many releases? Adjust CI settings?

This project has 66 releases. Every merge, mergify adds a release. Your workflow involves a lot of merges. The changelogs are commits lists, and usually most of the changes are duplicated, making it hard to see what is different between releases.

The best way to easily follow the progress of a github project is by watching the releases, but with vimspector it's too easy to get lost in the flood. Could I request, if possible, that you update mergify or whatever other tool is used, so that releases are only done when you think the project is ready for a new release?

I'm possibly making an issue out of something very small here, but I thought I may as well ask.

Errors when vimspector is not current tab

When there is a break and vimsepctor is not current, the UI errors due to the code window not being in the current tab.

Start debugging
gt
step/break (e.g. F11)

See error.

Can't send message: Job is not running

Describe the bug
When running the debug mode in vimspector, all windows are empty and i get the error message:

Can't send message: Job is not running

To Reproduce
List of steps to reproduce

Vimspector config file:

{
  "adapters": {
    "hda": {
      "name": "haskell-debug-adapter",
      "command": [
        "haskell-debug-adapter",
        "--hackage-version=0.0.31.0"
      ]
    }
  },
  "configurations": {
    "haskell-debug-adapter: Launch": {
      "adapter": "hda",
      "configuration": {
        "type": "ghc",
        "request": "launch",
        "name": "haskell-debug-adapter",
        "internalConsoleOptions": "openOnSessionStart",
        "workspace": "${workspaceRoot}",
        "startup": "${workspaceRoot}/app/Main.hs",
        "startupFunc": "",
        "startupArgs": "",
        "stopOnEntry": false,
        "mainArgs": "",
        "ghciPrompt": "H>>= ",
        "ghciInitialPrompt": "Prelude>",
        "ghciCmd": "stack ghci --test --no-load --no-build --main-is TARGET --ghci-options -fprint-evld-with-show",
        "ghciEnv": {},
        "logFile": "${workspaceRoot}/hdx4vim.log",
        "logLevel": "WARNING",
        "forceInspect": false
      }
    }
  }
}

Expected behavior
Launch the debug view and load all the windows with corresponding information.

Actual behaviour
See above.

Please include:

Vimspector log (~/.vimspector.log)

 cat .vimspector.log
2020-02-04 22:40:54,322 - INFO - **** INITIALISING NEW VIMSPECTOR SESSION ****
2020-02-04 22:40:54,322 - INFO - API is: neo
2020-02-04 22:40:54,322 - INFO - VIMSPECTOR_HOME = /home/daniel/.config/nvim/plugged/vimspector
2020-02-04 22:40:54,324 - INFO - gadgetDir = /home/daniel/.config/nvim/plugged/vimspector/gadgets/linux
2020-02-04 22:40:54,327 - DEBUG - Toggle found bp at /home/daniel/Documents/projects/lolhub/backend/app/Main.hs:50 ? False (New)
2020-02-04 22:40:56,379 - INFO - User requested start debug session with {}
2020-02-04 22:40:56,380 - DEBUG - Reading gadget config: /home/daniel/.config/nvim/plugged/vimspector/gadgets/linux/.gadgets.json
2020-02-04 22:40:56,381 - DEBUG - Reading gadget config: None
2020-02-04 22:40:56,382 - INFO - Configuration: {"adapter": "hda", "configuration": {"type": "ghc", "request": "launch", "name": "haskell-debug-adapter", "internalConsoleOptions": "openOnSessionStart", "workspace": "/home/daniel/Documents/projects/lolhub/backend", "startup": "/home/daniel/Documents/projects/lolhub/backend/app/Main.hs", "startupFunc": "", "startupArgs": "", "stopOnEntry": false, "mainArgs": "", "ghciPrompt": "H>>= ", "ghciInitialPrompt": "Prelude>", "ghciCmd": "stack ghci --test --no-load --no-build --main-is TARGET --ghci-options -fprint-evld-with-show", "ghciEnv": {}, "logFile": "/home/daniel/Documents/projects/lolhub/backend/hdx4vim.log", "logLevel": "WARNING", "forceInspect": false}}
2020-02-04 22:40:56,382 - INFO - Adapter: {"name": "haskell-debug-adapter", "command": ["haskell-debug-adapter", "--hackage-version=0.0.31.0"]}
2020-02-04 22:40:56,669 - INFO - Starting debug adapter with: {"name": "haskell-debug-adapter", "command": ["haskell-debug-adapter", "--hackage-version=0.0.31.0"]}
2020-02-04 22:40:56,670 - INFO - Debug Adapter Started
2020-02-04 22:40:56,670 - DEBUG - Sending Message: {"command": "initialize", "arguments": {"adapterID": "haskell-debug-adapter", "clientID": "vimspector", "clientName": "vimspector", "linesStartAt1": true, "columnsStartAt1": true, "locale": "en_GB", "pathFormat": "path", "supportsVariableType": true, "supportsVariablePaging": false, "supportsRunInTerminalRequest": true}, "seq": 0, "type": "request"}
2020-02-04 22:40:56,671 - DEBUG - Calling: vimspector#internal#neojob#Send(g:vimspector_internal_arg_0)
2020-02-04 22:41:11,673 - DEBUG - Timeout: Aborting request {'command': 'initialize', 'arguments': {'adapterID': 'haskell-debug-adapter', 'clientID': 'vimspector', 'clientName': 'vimspector', 'linesStartAt1': True, 'columnsStartAt1': True, 'locale': 'en_GB', 'pathFormat': 'path', 'supportsVariableType': True, 'supportsVariablePaging': False, 'supportsRunInTerminalRequest': True}, 'seq': 0, 'type': 'request'}
2020-02-04 22:41:11,673 - INFO - User Msg: Request for initialize aborted: Timeout

Output from any or all UI diagnostic tabs (Server, etc.)

Environemnt
Neovim 0.4.3

Output of vim --version or nvim --version

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Output of which vim or which nvim:

/usr/bin/nvim

Output of :py3 pass:

nothing

Output of :py3 import vim:

nothing

For neovim: output of :checkhealth

All ok, but ruby not installed

Operating system: and version
Arch Linux 5.5.1-arch1-1

[Feature Request]: Switch to debugpy rather than vscode-python

See #108 and #105 and a number of other complaints - we can't really rely on the way we're using vscode-python's typescript debug adapter anymore.

: Find a way to install debugpy using install_gadget.py
: Make install_gadget.py write a compatibility adapter config (should be trivial)
: Ensure that the regression tests still pass

Support for more terminal emulators

Describe the bug
Vimspector seems to work just fine for me if I use terminal.app. When telling Vimspector to launch a debugging session, a new terminal.app window spawns, some commands execute in the newly spawned window, and Vimspector properly starts debugging.

This also appears to be true for iTerm2. When telling Vimspector to launch a debugging session, a new terminal.app window spawns (NOT an iTerm2 window). The first time I performed this test, OSX asked me if I wanted to allow iTerm2 to control terminal.app. I said yes. Once this was performed, some commands execute in the newly spawned terminal.app window, and Vimspector properly starts debugging.

If I run this test with Kitty.app, however, Vimspector times out. In this case, telling Vimspector to launch a debugging session causes a terminal.app window to spawn (similar to iTerm2). However, I was never prompted about allowing kitty to control terminal.app. Therefore, no commands ever execute in the newly spawned terminal.app window. This results in Vimspector timing out.

To Reproduce
Attempt to use Vimspector with kitty.app. The result is a time out.
Using iTerm2 with Vimspector results in a terminal.app window spawning, not an iTerm2 window.

Vimspector config file:

{
  "configurations": {
    "TestName: Launch": {
      "adapter": "lldb-vscode",
      "configuration": {
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/a.out",
        "cwd": "${workspaceRoot}",
        "externalConsole": true,
        "stopAtEntry": true,
        "MIMode": "lldb",
        "logging": {
          "engineLogging": false
        }
      }
    },
    "TestName: Attach": {
      "adapter": "lldb-vscode",
      "configuration": {
        "name": "TestName: Attach",
        "type": "cppdbg",
        "request": "attach",
        "program": "${workspaceRoot}/a.out",
        "MIMode": "lldb"
      }
    }
  }
}

Expected behavior
There are a few things that would fulfill my expected behavior. One would be that the kitty project add support for controlling terminal.app the same way iTerm does. This should result in kitty.app working no differently than iTerm2.
However, I do find it odd that iTerm2 spawns a terminal.app window instead of a iTerm2 window. Perhaps, this is just a matter of OS configuration? If so, maybe we can document this in the readme?

Actual behaviour
kitty.app causes Vimspector to time out.
iTerm2 launches terminal.app, rather than launching an iTerm2 window.

Please include:

Vimspector log (~/.vimspector.log)

2020-01-23 10:30:26,440 - INFO - **** INITIALISING NEW VIMSPECTOR SESSION ****
2020-01-23 10:30:26,441 - INFO - API is: 
2020-01-23 10:30:26,441 - INFO - VIMSPECTOR_HOME = /Users/bbudzon/.vim/pack/natpack/opt/vimspector
2020-01-23 10:30:26,447 - INFO - gadgetDir = /Users/bbudzon/.vim/pack/natpack/opt/vimspector/gadgets/macos
2020-01-23 10:30:26,448 - INFO - User requested start debug session with {}
2020-01-23 10:30:26,448 - DEBUG - Reading gadget config: /Users/bbudzon/.vim/pack/natpack/opt/vimspector/gadgets/macos/.gadgets.json
2020-01-23 10:30:26,448 - DEBUG - Reading gadget config: /Users/bbudzon/.vim/pack/natpack/opt/vimspector/gadgets/macos/.gadgets.d/lldb-vscode.json
2020-01-23 10:30:26,449 - DEBUG - Reading gadget config: None
2020-01-23 10:30:29,117 - DEBUG - Set new_variables[ LLVM ] to '/usr/local/opt/llvm' from {'shell': 'brew --prefix llvm'} from {'shell': 'brew --prefix llvm'}
2020-01-23 10:30:29,117 - INFO - Configuration: {"adapter": "lldb-vscode", "configuration": {"type": "cppdbg", "request": "launch", "program": "/Users/bbudzon/srcbuild/test/a.out", "cwd": "/Users/bbudzon/srcbuild/test", "externalConsole": true, "stopAtEntry": true, "MIMode": "lldb", "logging": {"engineLogging": false}}}
2020-01-23 10:30:29,117 - INFO - Adapter: {"variables": {"LLVM": {"shell": "brew --prefix llvm"}}, "attach": {"pidProperty": "pid", "pidSelect": "ask"}, "command": ["/usr/local/opt/llvm/bin/lldb-vscode"], "env": {"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY": "NO"}, "name": "lldb"}
2020-01-23 10:30:29,198 - INFO - Starting debug adapter with: {"variables": {"LLVM": {"shell": "brew --prefix llvm"}}, "attach": {"pidProperty": "pid", "pidSelect": "ask"}, "command": ["/usr/local/opt/llvm/bin/lldb-vscode"], "env": {"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY": "NO"}, "name": "lldb"}
2020-01-23 10:30:29,205 - INFO - Debug Adapter Started
2020-01-23 10:30:29,205 - DEBUG - Sending Message: {"command": "initialize", "arguments": {"adapterID": "lldb", "clientID": "vimspector", "clientName": "vimspector", "linesStartAt1": true, "columnsStartAt1": true, "locale": "en_GB", "pathFormat": "path", "supportsVariableType": true, "supportsVariablePaging": false, "supportsRunInTerminalRequest": true}, "seq": 0, "type": "request"}
2020-01-23 10:30:29,205 - DEBUG - Calling: vimspector#internal#job#Send(g:vimspector_internal_arg_0)
2020-01-23 10:30:29,227 - INFO - Server stderr: error: module importing failed: loading unimplemented

2020-01-23 10:30:29,243 - DEBUG - Message received: {'body': {'exceptionBreakpointFilters': [{'default': False, 'filter': 'cpp_catch', 'label': 'C++ Catch'}, {'default': False, 'filter': 'cpp_throw', 'label': 'C++ Throw'}, {'default': False, 'filter': 'objc_catch', 'label': 'Objective C Catch'}, {'default': False, 'filter': 'objc_throw', 'label': 'Objective C Throw'}, {'default': False, 'filter': 'swift_catch', 'label': 'Swift Catch'}, {'default': False, 'filter': 'swift_throw', 'label': 'Swift Throw'}], 'supportTerminateDebuggee': True, 'supportsCompletionsRequest': False, 'supportsConditionalBreakpoints': True, 'supportsConfigurationDoneRequest': True, 'supportsDelayedStackTraceLoading': True, 'supportsEvaluateForHovers': True, 'supportsExceptionInfoRequest': True, 'supportsExceptionOptions': True, 'supportsFunctionBreakpoints': True, 'supportsGotoTargetsRequest': False, 'supportsHitConditionalBreakpoints': True, 'supportsLoadedSourcesRequest': False, 'supportsModulesRequest': False, 'supportsRestartFrame': False, 'supportsRestartRequest': False, 'supportsSetVariable': True, 'supportsStepBack': False, 'supportsStepInTargetsRequest': False, 'supportsValueFormattingOptions': True}, 'command': 'initialize', 'request_seq': 0, 'seq': 0, 'success': True, 'type': 'response'}
2020-01-23 10:30:29,244 - DEBUG - LAUNCH!
2020-01-23 10:30:29,244 - DEBUG - Sending Message: {"command": "launch", "arguments": {"type": "cppdbg", "request": "launch", "program": "/Users/bbudzon/srcbuild/test/a.out", "cwd": "/Users/bbudzon/srcbuild/test", "externalConsole": true, "stopAtEntry": true, "MIMode": "lldb", "logging": {"engineLogging": false}, "name": "test"}, "seq": 1, "type": "request"}
2020-01-23 10:30:29,244 - DEBUG - Calling: vimspector#internal#job#Send(g:vimspector_internal_arg_0)
2020-01-23 10:30:44,248 - DEBUG - Timeout: Aborting request {'command': 'launch', 'arguments': {'type': 'cppdbg', 'request': 'launch', 'program': '/Users/bbudzon/srcbuild/test/a.out', 'cwd': '/Users/bbudzon/srcbuild/test', 'externalConsole': True, 'stopAtEntry': True, 'MIMode': 'lldb', 'logging': {'engineLogging': False}, 'name': 'test'}, 'seq': 1, 'type': 'request'}
2020-01-23 10:30:44,249 - INFO - User Msg: Request for launch aborted: Timeout

Output from any or all UI diagnostic tabs (Server, etc.)

Did not see any output here.

Environment

NOTE: NeoVim is not supported.
NOTE: Windows is not supported.

Output of vim --version

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan  8 2020 08:55:30)
macOS version
Compiled by [email protected]
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       -tcl
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
-balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            -netbeans_intg     +termresponse
-browse            -gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     +perl              +title
+cindent           +job               +persistent_undo   -toolbar
-clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           -python            +visual
+comments          +linebreak         +python3           +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        -lua               +ruby              +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con        +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       -X11
+digraphs          +mouse             -sound             -xfontset
-dnd               -mouseshape        +spell             -xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        -mouse_gpm         +statusline        -xsmp
+eval              -mouse_jsbterm     -sun_workshop      -xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -L.  -L/usr/local/lib -o vim        -lm -lncurses  -liconv -framework AppKit   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE -lperl  -L/usr/local/opt/python/Frameworks/Python.framework/Versions/3.7/lib/python3.7/config-3.7m-darwin -lpython3.7m -framework CoreFoundation  -lruby.2.3.0 -ldl -lobjc

Output of which vim:

/usr/local/bin/vim

Output of :py3 pass:

I did not receive any output from this command?

Operating system: macOS 10.14.6

Additional context
One thing I did notice is that iTerm2 has the ability to control terminal.app via OSX Security settings. Kitty does not have this and I presume is why kitty behaves differently than iTerm2 (although I'm not entirely certain that iTerm2's behavior is desirable).

[Question] Gdb console is not modifiable

First, thanks for the plugin, is looking great!
I am testing it in neovim 0.4.3

Plug 'puremourning/vimspector', {'do': './install_gadget.py --enable-c --enable-python'}

.vimspector.json

{
  "configurations": {
    "<name>: Launch": {
      "adapter": "vscode-cpptools",
      "configuration": {
        "name": "<name>",
        "type": "cppdbg",
        "request": "launch",
        "program": "path/to/testSplitFunctions",
        "cwd": "/path/to/build",
        "environment": [],
        "MIMode": "gdb"
      }
    }
}

When running, the vimspector.Console buffer is not modifiable

Maybe this is in the area of vscode configuration, but it would be great to have a minimal example with interactive gdb in the docs.

Thanks

[Feature Request]: Support C# Samsung debugger

I'd be interested in adding C# support with the new Samsung debugger: https://github.com/Samsung/netcoredbg

I know there were discussions about it using the Microsoft vsdbg, but that didn't go anywhere because of licensing issues.

@puremourning do you know anything about this? I feel like I saw a pr or something that added that support and I was trying to find that to go off of, but use the Samsung debugger instead.

[Feature Request]: User interface, silent errors if not connected

Is your feature request related to a problem? Please describe.
Press f6 (Pause) or f10 (next) without connection gets an error message (here for f10)

Error detected while processing function vimspector#StepOver:
line    1:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home2/tourneboeuf/.vim/pack/bundle/opt/spector/python3/vimspector/debug_session.py", line 306, in StepOver
    if self._stackTraceView.GetCurrentThreadId() is None:
AttributeError: 'NoneType' object has no attribute 'GetCurrentThreadId'

Describe the solution you'd like

Hide the error message with:

if self._stackTraceView is None or self._stackTraceView.GetCurrentThreadId() is None:

instead of

self._stackTraceView.GetCurrentThreadId() is None:

Echo a nice little message MessageUser with a warning color asking him to connect first
Autoconnect ?

Describe alternatives you've considered

Do the first stepOver() is auto connecting if not connected ?
Is is preferable to silence the error, and even no message

Additional context
My solution would be 1, 2, 3. I'd be glad to make those changes with your desired solution.

Unable to debug python with node 13 environment. "Number of constructor arguments..."

Describe the bug

Starting to debug a basic python file opens vimspector windows but no debugging starts. Vimspector encounters an error and crashes.

To Reproduce

vim test.py
iprint('hello')
<f5>

Vimspector config file:

{
  "configurations": {
    "univisal: Launch": {
      "adapter": "vscode-python",
      "configuration": {
        "name": "<name>: Launch",
        "type": "python",
        "request": "launch",
        "cwd": "${workspaceRoot}",
        "stopOnEntry": true,
        "console": "externalTerminal",
        "debugOptions": [],
        "program": "${file}"
      }
    }
  }
}

Expected behavior

A debugging session starts

Actual behaviour

Vimspector windows open but no debugging starts.

No output except stderr, and that was the same as the contents of the log.

Environemnt

Version of Vimspector: (e.g. output of git rev-parse HEAD if cloned or the
name of the tarball used to install otherwise)

c6c0144

Output of vim --version or nvim --version

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Jan 26 2020 11:45:38)
Included patches: 1-148
Compiled by Arch Linux
Huge version with GTK3 GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       +tcl/dyn
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
+balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            +netbeans_intg     +termresponse
+browse            +gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     +perl/dyn          +title
+cindent           +job               +persistent_undo   +toolbar
+clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           +python/dyn        +visual
+comments          +linebreak         +python3/dyn       +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        +lua/dyn           +ruby/dyn          +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con_gui    +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       +X11
+digraphs          +mouse             +sound             -xfontset
+dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        +mouse_gpm         +statusline        +xsmp_interact
+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary        
   system vimrc file: "/etc/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "/etc/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread    -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_REENTRANT  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linking: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf -lnsl    -lcanberra  -lacl -lattr -lgpm -ldl   -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/perl5/5.30/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc   -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm

Output of which vim or which nvim:

/usr/bin/vim

Output of :py3 pass: no output
Output of :py3 import vim: No output
Operating system: Arch linux updated today

Vimspector.log:

2020-01-30 21:51:13,867 - INFO - **** INITIALISING NEW VIMSPECTOR SESSION ****
2020-01-30 21:51:13,867 - INFO - API is: 
2020-01-30 21:51:13,867 - INFO - VIMSPECTOR_HOME = /home/user/.vim/plugins/vimspector
2020-01-30 21:51:13,868 - INFO - gadgetDir = /home/user/.vim/plugins/vimspector/gadgets/linux
2020-01-30 21:52:20,008 - INFO - User requested start debug session with {}
2020-01-30 21:52:20,009 - DEBUG - Reading gadget config: /home/user/.vim/plugins/vimspector/gadgets/linux/.gadgets.json
2020-01-30 21:52:20,010 - DEBUG - Reading gadget config: None
2020-01-30 21:52:20,011 - INFO - Configuration: {"adapter": "vscode-python", "configuration": {"name": "<name>: Launch", "type": "python", "request": "launch", "cwd": "/home/user/src/Univisal", "stopOnEntry": true, "console": "externalTerminal", "debugOptions": [], "program": "/home/user/src/Univisal/test.py"}}
2020-01-30 21:52:20,011 - INFO - Adapter: {"command": ["node", "/home/user/.vim/plugins/vimspector/gadgets/linux/vscode-python/out/client/debugger/debugAdapter/main.js"], "name": "vscode-python"}
2020-01-30 21:52:20,444 - INFO - Starting debug adapter with: {"command": ["node", "/home/user/.vim/plugins/vimspector/gadgets/linux/vscode-python/out/client/debugger/debugAdapter/main.js"], "name": "vscode-python"}
2020-01-30 21:52:20,534 - INFO - Debug Adapter Started
2020-01-30 21:52:20,534 - DEBUG - Sending Message: {"command": "initialize", "arguments": {"adapterID": "vscode-python", "clientID": "vimspector", "clientName": "vimspector", "linesStartAt1": true, "columnsStartAt1": true, "locale": "en_GB", "pathFormat": "path", "supportsVariableType": true, "supportsVariablePaging": false, "supportsRunInTerminalRequest": true}, "seq": 0, "type": "request"}
2020-01-30 21:52:20,534 - DEBUG - Calling: vimspector#internal#job#Send(g:vimspector_internal_arg_0)
2020-01-30 21:52:20,566 - DEBUG - Message received: {'seq': 0, 'type': 'event', 'event': 'error', 'body': 'Debugger Error: The number of constructor arguments in the derived class s must be >= than the number of constructor arguments of its base class.'}
2020-01-30 21:52:20,567 - WARNING - User Msg: Unhandled event: error
2020-01-30 21:52:20,567 - DEBUG - Message received: {'seq': 0, 'type': 'event', 'event': 'output', 'body': {'category': 'stderr', 'output': 'Debugger Error: The number of constructor arguments in the derived class s must be >= than the number of constructor arguments of its base class.\nDebugger Error: The number of constructor arguments in the derived class s must be >= than the number of constructor arguments of its base class.\nError\nError: The number of constructor arguments in the derived class s must be >= than the number of constructor arguments of its base class.\n    at /home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:27311\n    at Array.forEach (<anonymous>)\n    at e (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:26875)\n    at Object.t.plan (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:27386)\n    at /home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:24044\n    at e._get (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:23953)\n    at e.get (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:16:22664)\n    at s.get (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:68:141080)\n    at new _ (/home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:1:268522)\n    at /home/user/.vim/plugins/vimspector/gadgets/linux/download/vscode-python/2019.11.50794/root/extension/out/client/debugger/debugAdapter/main.js:1:271764'}}
2020-01-30 21:52:20,603 - INFO - The server has terminated with status 0
2020-01-30 21:52:20,603 - DEBUG - Closing down: Aborting request {'command': 'initialize', 'arguments': {'adapterID': 'vscode-python', 'clientID': 'vimspector', 'clientName': 'vimspector', 'linesStartAt1': True, 'columnsStartAt1': True, 'locale': 'en_GB', 'pathFormat': 'path', 'supportsVariableType': True, 'supportsVariablePaging': False, 'supportsRunInTerminalRequest': True}, 'seq': 0, 'type': 'request'}
2020-01-30 21:52:20,603 - INFO - User Msg: Request for initialize aborted: Closing down
2020-01-30 21:52:20,637 - DEBUG - No server exit handler
2020-01-30 21:52:23,597 - INFO - Debugging complete.
2020-01-30 21:52:23,598 - DEBUG - Clearing down UI with stack_trace: ['  File "<string>", line 1, in <module>\n', '  File "/home/user/.vim//plugins/vimspector/python3/vimspector/debug_session.py", line 300, in Reset\n    self._Reset()\n', '  File "/home/user/.vim//plugins/vimspector/python3/vimspector/debug_session.py", line 306, in _Reset\n    traceback.format_stack() )\n']

[Feature Request]: Console window improvements

So today I gave the first test drive for vimspector and I have a few comments.

First of all, Ideally, I'd expect the plugin to provide a visual mode mapping that will put the currently selected text in the console. That doesn't exist for AFAIK.

The above wouldn't have been such of an inconvenience if the console window was more comfortable. It's not clear (to me) whether it's a terminal, or a normal buffer with very special mappings.. For example, there's no undo and C-c doesn't cancel the current line entered and the up-down arrows don't put the previous commands in the line..

Wouldn't it have been better to use Vim's input("Vimspector > ")? I'm just speculating that other Vim plugins have found a better way for sending arbitrary input to other programs / jobs' stdin. Maybe it would be better to have a script that will connect (somehow - I'm not saying it'll be easy) to the debugger and launch this script inside a :terminal? I think it'll take down most of the hassle that has been put down to make that console window in the first place.

BTW, what else does the vimspector.Console window does? I'm just curios whether it's worth the space it takes from the window.

Besides that, I must say that the debugging tab is designed excellently! Was this inspired by Vs-code? I haven't used yet the watches but the stacktrace window getting updated all the time is truly awesome. Also being able to play the buttons at the top of the code window is pretty cool 👍.

I don't want to sound too critical, I just feel like this plugin is the true (the one 💍 ) plugin that will finally bring standardized debugging capabilities to Vim in that {DA,LS}P way. That's why I'm putting my time into suggesting ideas that will hopefully improve it.

[Feature Request]: Ability to programmatically set the DAP communication port.

Is your feature request related to a problem? Please describe.
I'd like to be able to take the communication port number result of the vscode.java.startDebugSession command and pass it to vimspector when starting it.

#3 (comment)

Describe the solution you'd like
I think what I'm looking for is a function in the vimspector public API which takes the DAP communication port as an argument. It would be callable from viml.

Describe alternatives you've considered
I haven't considered any alternatives though I'm open to anything to streamline the process of using a random DAP communication port and getting that information seamlessly passed to vimspector.

Additional context
See this ticket #3 (comment) for additional context.

[Feature Request]: Why are all of those questions when starting a debug session?

So today, when I've started my first ever debug session I was asked:

Enable exception filter 'Raised Exceptions'? (Y/N)
Enable exception filter 'Uncaught Exceptions'? (Y/N)
When to break on exception?
1: never
2: always
3: unhandled
4: userHandled
Type number and <Enter> or click with mouse (empty cancels):

And only then the debugging has started. Is it possible to make give these answers default answers for the whole project / adapter / all adapters? Say I don't understand what are these questions all about, where could I find a documentation for it?

No example configuration for bash debugger

Bash debugging does not work, I don't really understand how to make it work.

I put let g:vimspector_enable_mappings = 'VISUAL_STUDIO' at the top of my vimrc, then later I call Plug 'puremourning/vimspector', my vimspector config is pasted below. Now when I press F9 to toggle breakpoint nothing happens, however :call vimspector#ToggleBreakpoint() successfully toggles the breakpoint. At least the F5 shortcut works and opens something, but the program does not halt at my breakpoint, instead I get:

From client: initialize({"adapterID":"bashdb","clientID":"vimspector","clientName":"vimspector","linesStartAt1":true,"columnsStartAt1":true,"locale":"en_GB","pathFormat":"path","supportsVariableType":true,"supportsVariablePaging":false,"supportsRunInTerminalRequest":true})
To client: {"seq":0,"type":"response","request_seq":0,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":true,"supportsStepBack":false,"supportsSetVariable":false}}
From client: launch({"type":"bashdb","request":"launch","name":"Bash-Debug (simple)","program":"./link.sh","args":[],"cwd":"/home/magnus/.dotfiles","pathBash":"bash","pathBashdb":"/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb","pathCat":"cat","pathMkfifo":"mkfifo","pathPkill":"pkill","showDebugOutput":true,"trace":true})
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stderr","output":"::PROXYID::31567\n"}}

Vimspector config file:

{
	"adapters": {
		"bashdb": {
			"name": "bashdb",
			"command": [
				"node",
				"$HOME/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/out/bashDebug.js"
			]
		}
	},
	"configurations": {
		"bashdb": {
			"adapter": "bashdb",
			"configuration": {
				"type": "bashdb",
				"request": "launch",
				"name": "Bash-Debug (simple)",
				"program": "./link.sh",
				"args": [],
				"cwd": "$HOME/.dotfiles",
				"pathBash": "bash",
				"pathBashdb": "~/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb",
				"pathCat": "cat",
				"pathMkfifo": "mkfifo",
				"pathPkill": "pkill",
				"showDebugOutput": true,
				"trace": true
			}
		}
	}
}

Vimspector log:

2020-01-30 21:02:45,670 - INFO - **** INITIALISING NEW VIMSPECTOR SESSION ****
2020-01-30 21:02:45,670 - INFO - API is: 
2020-01-30 21:02:45,670 - INFO - VIMSPECTOR_HOME = /home/magnus/.vim/plugged/vimspector
2020-01-30 21:02:45,673 - INFO - gadgetDir = /home/magnus/.vim/plugged/vimspector/gadgets/linux
2020-01-30 21:02:45,673 - DEBUG - Toggle found bp at /home/magnus/.dotfiles/link.sh:76 ? False (New)
2020-01-30 21:02:51,710 - INFO - User requested start debug session with {}
2020-01-30 21:02:51,711 - DEBUG - Reading gadget config: /home/magnus/.vim/plugged/vimspector/gadgets/linux/.gadgets.json
2020-01-30 21:02:51,712 - DEBUG - Reading gadget config: None
2020-01-30 21:02:51,714 - INFO - Configuration: {"adapter": "bashdb", "configuration": {"type": "bashdb", "request": "launch", "name": "Bash-Debug (simple)", "program": "./link.sh", "args": [], "cwd": "/home/magnus/.dotfiles", "pathBash": "bash", "pathBashdb": "/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb", "pathCat": "cat", "pathMkfifo": "mkfifo", "pathPkill": "pkill", "showDebugOutput": true, "trace": true}}
2020-01-30 21:02:51,714 - INFO - Adapter: {"name": "bashdb", "command": ["node", "/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/out/bashDebug.js"]}
2020-01-30 21:02:51,740 - INFO - Starting debug adapter with: {"name": "bashdb", "command": ["node", "/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/out/bashDebug.js"]}
2020-01-30 21:02:51,744 - INFO - Debug Adapter Started
2020-01-30 21:02:51,744 - DEBUG - Sending Message: {"command": "initialize", "arguments": {"adapterID": "bashdb", "clientID": "vimspector", "clientName": "vimspector", "linesStartAt1": true, "columnsStartAt1": true, "locale": "en_GB", "pathFormat": "path", "supportsVariableType": true, "supportsVariablePaging": false, "supportsRunInTerminalRequest": true}, "seq": 0, "type": "request"}
2020-01-30 21:02:51,745 - DEBUG - Calling: vimspector#internal#job#Send(g:vimspector_internal_arg_0)
2020-01-30 21:02:51,811 - DEBUG - Message received: {'seq': 1, 'type': 'response', 'request_seq': 0, 'command': 'initialize', 'success': True, 'body': {'supportsConditionalBreakpoints': True, 'supportsConfigurationDoneRequest': False, 'supportsEvaluateForHovers': True, 'supportsStepBack': False, 'supportsSetVariable': False}}
2020-01-30 21:02:51,811 - DEBUG - LAUNCH!
2020-01-30 21:02:51,811 - DEBUG - Sending Message: {"command": "launch", "arguments": {"type": "bashdb", "request": "launch", "name": "Bash-Debug (simple)", "program": "./link.sh", "args": [], "cwd": "/home/magnus/.dotfiles", "pathBash": "bash", "pathBashdb": "/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb", "pathCat": "cat", "pathMkfifo": "mkfifo", "pathPkill": "pkill", "showDebugOutput": true, "trace": true}, "seq": 1, "type": "request"}
2020-01-30 21:02:51,811 - DEBUG - Calling: vimspector#internal#job#Send(g:vimspector_internal_arg_0)
2020-01-30 21:02:51,823 - DEBUG - Message received: {'seq': 2, 'type': 'event', 'event': 'output', 'body': {'category': 'stdout', 'output': 'From client: initialize({"adapterID":"bashdb","clientID":"vimspector","clientName":"vimspector","linesStartAt1":true,"columnsStartAt1":true,"locale":"en_GB","pathFormat":"path","supportsVariableType":true,"supportsVariablePaging":false,"supportsRunInTerminalRequest":true})\n'}}
2020-01-30 21:02:51,824 - DEBUG - Message received: {'seq': 3, 'type': 'event', 'event': 'output', 'body': {'category': 'stdout', 'output': 'To client: {"seq":0,"type":"response","request_seq":0,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":true,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":true,"supportsStepBack":false,"supportsSetVariable":false}}\n'}}
2020-01-30 21:02:51,824 - DEBUG - Message received: {'seq': 4, 'type': 'event', 'event': 'output', 'body': {'category': 'stdout', 'output': 'From client: launch({"type":"bashdb","request":"launch","name":"Bash-Debug (simple)","program":"./link.sh","args":[],"cwd":"/home/magnus/.dotfiles","pathBash":"bash","pathBashdb":"/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb","pathCat":"cat","pathMkfifo":"mkfifo","pathPkill":"pkill","showDebugOutput":true,"trace":true})\n'}}
2020-01-30 21:02:51,825 - INFO - Server stderr: (node:31657) UnhandledPromiseRejectionWarning: TypeError: Cannot convert undefined or null to object
    at Function.keys (<anonymous>)
    at BashDebugSession.launchRequest (/home/magnus/.vim/plugged/vimspector/gadgets/linux/download/vscode-bash-debug/v0.3.6/root/extension/out/bashDebug.js:83:30)
    at BashDebugSession.dispatchRequest (/home/magnus/.vim/plugged/vimspector/gadgets/linux/download/vscode-bash-debug/v0.3.6/root/extension/node_modules/vscode-debugadapter/lib/debugSession.js:342:22)
    at BashDebugSession.dispatchRequest (/home/magnus/.vim/plugged/vimspector/gadgets/linux/download/vscode-bash-debug/v0.3.6/root/extension/node_modules/vscode-debugadapter/lib/loggingDebugSession.js:48:15)
    at BashDebugSession._handleData (/home/magnus/.vim/plugged/vimspector/gadgets/linux/download/vscode-bash-debug/v0.3.6/root/extension/node_modules/vscode-debugadapter/lib/protocol.js:97:38)
    at Socket.<anonymous> (/home/magnus/.vim/plugged/vimspector/gadgets/linux/download/vscode-bash-debug/v0.3.6/root/extension/node_modules/vscode-debugadapter/lib/protocol.js:18:44)
    at Socket.emit (events.js:321:20)
    at addChunk (_stream_readable.js:297:12)
    at readableAddChunk (_stream_readable.js:273:9)
    at Socket.Readable.push (_stream_readable.js:214:10)

2020-01-30 21:02:51,827 - DEBUG - Message received: {'seq': 5, 'type': 'event', 'event': 'output', 'body': {'category': 'stdout', 'output': 'To client: {"seq":0,"type":"event","event":"output","body":{"category":"stderr","output":"::PROXYID::31674\\n"}}\n'}}
2020-01-30 21:02:51,827 - DEBUG - Message received: {'seq': 6, 'type': 'event', 'event': 'output', 'body': {'category': 'stderr', 'output': '::PROXYID::31674\n'}}
2020-01-30 21:02:51,829 - INFO - Server stderr: (node:31657) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:31657) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

2020-01-30 21:03:06,823 - DEBUG - Timeout: Aborting request {'command': 'launch', 'arguments': {'type': 'bashdb', 'request': 'launch', 'name': 'Bash-Debug (simple)', 'program': './link.sh', 'args': [], 'cwd': '/home/magnus/.dotfiles', 'pathBash': 'bash', 'pathBashdb': '/home/magnus/.vim/plugged/vimspector/gadgets/linux/vscode-bash-debug/bashdb_dir/bashdb', 'pathCat': 'cat', 'pathMkfifo': 'mkfifo', 'pathPkill': 'pkill', 'showDebugOutput': True, 'trace': True}, 'seq': 1, 'type': 'request'}
2020-01-30 21:03:06,824 - INFO - User Msg: Request for launch aborted: Timeout

Environemnt

Version of Vimspector: c1851a3
Output of vim --version:

VIM - Vi IMproved 8.2 (2019 Dec 12 kompiliert am Jan 26 2020 11:45:38)
Inklusive der Patches: 1-148
Übersetzt von Arch Linux
Riesige Version mit GTK3 GUI.
 Ein- (+) oder ausschließlich (-) der Eigenschaften:
+acl               -farsi             -mouse_sysmouse    -tag_old_static
+arabic            +file_in_path      +mouse_urxvt       -tag_any_white
+autocmd           +find_in_path      +mouse_xterm       +tcl/dyn
+autochdir         +float             +multi_byte        +termguicolors
-autoservername    +folding           +multi_lang        +terminal
+balloon_eval      -footer            -mzscheme          +terminfo
+balloon_eval_term +fork()            +netbeans_intg     +termresponse
+browse            +gettext           +num64             +textobjects
++builtin_terms    -hangul_input      +packages          +textprop
+byte_offset       +iconv             +path_extra        +timers
+channel           +insert_expand     +perl/dyn          +title
+cindent           +job               +persistent_undo   +toolbar
+clientserver      +jumplist          +popupwin          +user_commands
+clipboard         +keymap            +postscript        +vartabs
+cmdline_compl     +lambda            +printer           +vertsplit
+cmdline_hist      +langmap           +profile           +virtualedit
+cmdline_info      +libcall           +python/dyn        +visual
+comments          +linebreak         +python3/dyn       +visualextra
+conceal           +lispindent        +quickfix          +viminfo
+cryptv            +listcmds          +reltime           +vreplace
+cscope            +localmap          +rightleft         +wildignore
+cursorbind        +lua/dyn           +ruby/dyn          +wildmenu
+cursorshape       +menu              +scrollbind        +windows
+dialog_con_gui    +mksession         +signs             +writebackup
+diff              +modify_fname      +smartindent       +X11
+digraphs          +mouse             +sound             -xfontset
+dnd               +mouseshape        +spell             +xim
-ebcdic            +mouse_dec         +startuptime       -xpm
+emacs_tags        +mouse_gpm         +statusline        +xsmp_interact
+eval              -mouse_jsbterm     -sun_workshop      +xterm_clipboard
+ex_extra          +mouse_netterm     +syntax            -xterm_save
+extra_search      +mouse_sgr         +tag_binary        
          System-vimrc-Datei: "/etc/vimrc"
        Benutzer-vimrc-Datei: "$HOME/.vimrc"
 zweite Benutzer-vimrc-Datei: "~/.vim/vimrc"
         Benutzer-exrc-Datei: "$HOME/.exrc"
         System-gvimrc-Datei: "/etc/gvimrc"
       Benutzer-gvimrc-Datei: "$HOME/.gvimrc"
zweite Benutzer-gvimrc-Datei: "~/.vim/gvimrc"
      defaults Datei: "$VIMRUNTIME/defaults.vim"
           System-Menü-Datei: "$VIMRUNTIME/menu.vim"
     Voreinstellung für $VIM: "/usr/share/vim"
Übersetzt: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -I/usr/include/gtk-3.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -I/usr/include/harfbuzz -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -pthread    -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_REENTRANT  -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1       
Linken: gcc   -L. -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE  -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-3 -lgdk-3 -lz -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0  -lSM -lICE -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lelf -lnsl    -lcanberra  -lacl -lattr -lgpm -ldl   -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.30/core_perl/CORE -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -fstack-protector-strong -L/usr/local/lib  -L/usr/lib/perl5/5.30/core_perl/CORE -lperl -lpthread -ldl -lm -lcrypt -lutil -lc   -L/usr/lib -ltclstub8.6 -ldl -lz -lpthread -lm

Output of which vim or which nvim:

vim: aliased to vim --servername vim
(system vim)

Operating system: Arch Linux latest

I guess the error in the log might have something to do with it.

[Feature Request]: Highlight changed variables

It would be very useful to see which variables change between steps. For example lldb's TUI highlights those with red:

[Feature Request]: Breakpoints window

Breakpoints can be displayed int he location list, but this is weak and not fully implemented.

We need a breakpoints window to list all breakpoints, allowing:

move/edit/enable/disable
view for line and function breakpoints
etc.

UI wise, it's not obvious where to put this.

Python: Attach to process not working with vscode-cpptools

Describe the bug

Python attach fails with "Session is not initialised". This appears to be a bug in vscode-cpptools, but requires more investigation. In practice, however, simply attaching directly to the ptvsd port works perfectly, so perhaps that should be the recommended approach, i.e.

Start the application with python -m ptvsd --host localhost --port 1234 --wait ...
Attach to it directly with

    "python - attach ptvsd": {
      "adapter": {
        "name": "ptvsd",
        "port": 1234
      },
      "configuration": {
        "name": "attach",
        "type": "ptvsd",
        "request": "attach",
        "debugOptions":  [
          "RedirectOutput",
          "UnixClient",
          "ShowReturnValue"
        ]
      }
    }

To Reproduce

cd to support/test/python/simple_python
python -m ptvsd --wait --host localhost --port 1234 test.py
In another window, in same directory, set a breakpoint, and fire up vimspector, using the following config:

    "python - attach": {
      "adapter": "vscode-python",
      "variables": [
        {
          "python": {
            "shell": "/bin/bash -c 'if [ -z \"${dollar}VIRTUAL_ENV\" ]; then echo $$(which python); else echo \"${dollar}VIRTUAL_ENV/bin/python\"; fi'"
          }
        }
      ],
      "configuration": {
        "name": "Python attach",
        "type": "vscode-python",
        "request": "attach",

        "pythonPath": "${python}",
        "host": "localhost",
        "port": "${port}"
      }
    },

Expected behavior

Vimspector starts and attaches to the app

Actual behaviour

It never attaches, and the vscode-python node debug adapter spits out an error (which you can see in the console of the test.py that the session is not initialized. This is clearly a vscode-python bug and/or incompatibility with ptvsd (it doesn't appear to send a DAP initialise request).

Support Dart language.

Hi. Thank you for this great effort. It's awesome to add Dart language support to vimspector. Is it possible at all?

No tests for actual debugging

There's a test framework but no real tests.

Add some tests, at least:

Start up and debug a C program
Setting/clearing breakpoints
Reset - hopefully will get a repro of the frequent vim crashes
Restart - I keep breaking this one.

etc.

[Feature Request]: PowerShell support

Describe the solution you'd like
This is the issue to discuss what we need to do to support PowerShell Editor Services PowerShell's language server and debug adapter.

Additional context
PowerShell Editor Services uses Named Pipes/unix domain sockets for the communication layer. This is because we typically have the LSP and DAP being used at the same time.

In vscode, we bridge stdio to the named pipes using this TypeScript file which acts as the "entry point" or "executable" for vscode.

I think we can leverage this as well for vimspector.

My ideal situation is to start PowerShell Editor Services up with either coc-powershell or YCM (which I'd love guidance on :)) and then connect to that using vimspector.

What do you think? 😄

[Feature Request]: CentOS6 support (glibc 2.12)

Hi,

Is it possible to run this plugin on CentOS6 machine?

I follow the instructions as described in https://puremourning.github.io/vimspector-web/demo-setup.html to install Vimspector and run a simple C problem.

I pressed Press F5 to start debugging but it failed due to GLIBC issue. Following is the relevant output of _vimspector_log_Vimspector_out

2019-12-23 11:11:25,966 - INFO - Server stderr: /u/ming/.vim/pack/vimspector/opt/vimspector/gadgets/linux/download/vscode-cpptools/0.26.2/root/extension/debugAdapters/mono.linux-x86_64: /lib64/libc.so.6: version `GLIBC_2.15' not found (required by /u/ming/.vim/pack/vimspector/opt/vimspector/gadgets/linux/download/vscode-cpptools/0.26.2/root/extension/debugAdapters/mono.linux-x86_64)

2019-12-23 11:11:25,992 - INFO - Server stderr: /u/ming/.vim/pack/vimspector/opt/vimspector/gadgets/linux/download/vscode-cpptools/0.26.2/root/extension/debugAdapters/mono.linux-x86_64: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /u/ming/.vim/pack/vimspector/opt/vimspector/gadgets/linux/download/vscode-cpptools/0.26.2/root/extension/debugAdapters/mono.linux-x86_64)

Error detected while processing function vimspector#Launch[1]..provider#python3#Call

I'm on macOS with Python 3 and Node 10. I've installed vimspector using vim-plug and the following configuration line:

Plug 'puremourning/vimspector', { 'do': './install_gadget.py --enable-chrome --enable-node' }

And added a .vimspector.json to the root of my project with the following basic config:

{
  "configurations": {
    "myproject: Attach": {
      "adapter": "chrome",
      "configuration": {
        "request": "attach",
        "url": "http://localhost:3000/",
        "webRoot": "${workspaceRoot}/src"
      }
    }
  }
}

And when I try to call Launch or Continue, for example :call vimspector#Launch() I just get the following error:

Error detected while processing function vimspector#Launch[1]..provider#python3#Call:
line   18:
Error invoking 'python_execute' on channel 8 (python3-script-host):
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/chriskahn/.local/share/nvim/plugged/vimspector/python3/vimspector/debug_session.py", line 195, in Start
    utils.ParseVariables( adapter.get( 'variables', {} ),
AttributeError: 'NoneType' object has no attribute 'get'
Press ENTER or type command to continue

Seems like it's failing at calling adapter.get('variables', {})? Is something missing?

Remote debugging is not documented

Vimspector supports some fairly powerful remote debugging features, as required by the author. These options are not documented and there is no tutorial.

[Feature Request]: Customise UI

There are three things that I would love to be able to configure from my .vimrc or .vimspector.json. If these options already exist then they haven't been documented in an easy to find way, as I've spent a while looking!

Persist a default option for the questions Break on all Exceptions? and Break on all Uncaught Exceptions?. As right now I have to answer them everytime I launch the debugger.
Configure what windows are displayed. Personally I don't use the StackTrace, Watcher and Variables windows. It would be nice if they could be disabled, to give more room for the other windows.
Configure placement and size of the debug windows. It would be great to define the % splits of each window. Something similar to Nuake would be awesome.

My workflow may be a bit different to others, as I work with TypeScript, so I thought you might like to hear about how I would ideally use vimspector in case it is totally different to how you would. I'd like to keep it really simple, be browsing and working on code, hit a key to add break points, then another to launch the debugger.

Rather than use watchers or variable windows, I would love to just have a responsive console (Like the JS developer console in chrome) that I could use to inspect and interact with variables. If it would be possible to have this (and the application output) open as Nuake does this would be excellent.

This is just my personal wishlist though, I started looking at how to achieve some of these things myself, but python+vimscript is new to me so I got a little scared!

Thanks for making vimspector, it's amazing, and something that has been missing from the Vim-ecosystem for ages! :D <3

Continue button typo

The continue button says 'Continute'

@ShedPlant

Vimspector is not properly shutting down when Reset is called

Describe the bug
A clear and concise description of what the bug is.

After calling vimspector#Reset() while debugging a java application using the eclipse.jdt.ls via YouCompleteMe, vimspector never resets. The vim tab remains open and the final messages logged by vimspector indicate the events that fire on exit are never called.

To Reproduce
List of steps to reproduce

Create an example java project using maven. Configure YouCompleteMe to use the eclipse.jdt.ls to perform completion (and to enable debugging)
Download the vscode java debugger extension, place it in your home directory
Set the following in your .vimrc: let g:ycm_java_jdtls_extension_path = [ '<your home dir>/<your vscode extensions directory>/' ]
Drop a breakpoint in a file in the project you desire to debug
Call YcmCompleter ExecuteCommand vscode.java.startDebugSession
Call vimspector#Launch()
Enter the port provided by YouCompleteMe to start vimspector
Once the debugger has attached, call vimspector#Reset()

Vimspector config file:

{
    "adapters": {
        "java-debug-server": {
            "name": "vscode-java",
            "port": "ask"
        }
    },
    "configurations": {
        "Java Launch": {
            "adapter": "java-debug-server",
            "configuration": {
                "request": "attach",
                "hostName": "localhost",
                "port": "5005",
                "sourcePaths": [ "${workspaceRoot}/**" ],
                "classPaths": [ "${workspaceRoot}/**/target/classes" ],
                "args": "",
                "stopOnEntry": true,
                "console": "integratedTerminal"
            }
        }
    }
}

Expected behavior
A clear and concise description of what you expected to happen.

I'd expect vimspector to close the tab that was opened when vimspector was launched and for vimspector to be ready to be used again (i.e., calling vimspector#Launch() again)

Actual behaviour
What actually happened, including output, log files etc.

Please include:

Vimspector log (~/.vimspector.log)
Output from any or all UI diagnostic tabs (Server, etc.)

The tab never closes; it remains open and vimspector is never put into a clean slate. If vimspector#Launch() is called again, vimspector dumps a bunch of erroneous output.

I can't dump the entire .vimspector.log here since it contains some work-related information. Here is the relevant information at the end of the file though:

Note that the contents below do contain all of the output at the end of the log; there is no other output below this

2019-10-01 14:52:57,903 - DEBUG - Message received: {'event': 'thread', 'body': {'reason': 'exited', 'threadId': 76, 'type': 'thread'}, 'seq': 395, 'type': 'event'}
2019-10-01 14:52:57,903 - DEBUG - Message received: {'event': 'exited', 'body': {'exitCode': 0, 'type': 'exited'}, 'seq': 396, 'type': 'event'}
2019-10-01 14:52:57,903 - INFO - User Msg: The debugee exited with status code: 0
2019-10-01 14:52:57,903 - DEBUG - Message received: {'event': 'exited', 'body': {'exitCode': 0, 'type': 'exited'}, 'seq': 397, 'type': 'event'}
2019-10-01 14:52:57,904 - INFO - User Msg: The debugee exited with status code: 0
2019-10-01 14:53:01,463 - DEBUG - Stop debug adapter with callback : self._Reset()
2019-10-01 14:53:01,464 - DEBUG - Sending Message: {"command": "disconnect", "arguments": {"terminateDebuggee": true}, "seq": 25, "type": "request"}
2019-10-01 14:53:01,465 - DEBUG - Message received: {'success': True, 'request_seq': 25, 'command': 'disconnect', 'seq': 398, 'type': 'response'}
2019-10-01 14:53:01,465 - DEBUG - Setting server exit handler before disconnect

If I call vimspector#Launch() again after calling vimspector#Reset(), the following output is returned:

Error detected while processing function vimspector#Launch:
line    1:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/debug_session.py", line 165, in Start
    self._StartWithConfiguration( configuration, adapter )
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/debug_session.py", line 213, in _StartWithConfiguration
    start()
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/debug_session.py", line 181, in start
    self._SetUpUI()
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/debug_session.py", line 363, in _SetUpUI
    vim.current.buffer )
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/stack_trace.py", line 33, in __init__
    utils.SetUpScratchBuffer( self._buf, 'vimspector.StackTrace' )
  File "/home/devynmapes/.vim/pack/my-plugins/start/vimspector/python3/vimspector/utils.py", line 88, in SetUpScratchBuffer
    buf.name = name
vim.error: Vim:E95: Buffer with this name already exists
Press ENTER or type command to continue

Of course this is due to the buffers never actually being closed when reset is called.

Environemnt

NOTE: NeoVim is not supported.
NOTE: Windows is not supported.

Output of vim --version

VIM - Vi IMproved 8.1 (2018 May 18, compiled Sep 03 2019 13:04:21)
Included patches: 1-1967
Modified by [email protected]
Compiled by [email protected]
Huge version without GUI.  Features included (+) or not (-):
+acl               -farsi             -mouse_sysmouse    -tag_any_white
+arabic            +file_in_path      +mouse_urxvt       -tcl
+autocmd           +find_in_path      +mouse_xterm       +termguicolors
+autochdir         +float             +multi_byte        +terminal
-autoservername    +folding           +multi_lang        +terminfo
-balloon_eval      -footer            -mzscheme          +termresponse
+balloon_eval_term +fork()            +netbeans_intg     +textobjects
-browse            +gettext           +num64             +textprop
++builtin_terms    -hangul_input      +packages          +timers
+byte_offset       +iconv             +path_extra        +title
+channel           +insert_expand     -perl              -toolbar
+cindent           +job               +persistent_undo   +user_commands
-clientserver      +jumplist          +postscript        +vartabs
-clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           -python            +visual
+cmdline_info      +libcall           +python3           +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          -ruby              +wildmenu
+cursorbind        -lua               +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con        +mksession         +smartindent       -X11
+diff              +modify_fname      -sound             -xfontset
+digraphs          +mouse             +spell             -xim
-dnd               -mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        -xsmp
+emacs_tags        +mouse_gpm         -sun_workshop      -xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary
+extra_search      +mouse_sgr         -tag_old_static
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H   -Wdate-time  -g -O2 -fdebug-prefix-map=/build/vim-I6gBP8/vim-8.1.1967=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: gcc   -Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim        -lm -ltinfo -lnsl  -lselinux  -lacl -lattr -lgpm -ldl     -L/usr/lib/python3.6/config-3.6m-x86_64-linux-gnu -lpython3.6m -lpthread -ldl -lutil -lm

Output of which vim:

/usr/bin/vim

Output of :py3 pass:

This isn't printing anything in my Vim version for whatever reason.

Operating system: and version

Ubuntu 16.04

Additional context
Add any other context about the problem here.

Can't disable breakpoint while debugging

Since moving breakpoints code around, you can no longer disable a breakpoint while actually debugging.

Set a breakpoint (F9)
Start debugging (F5)
When t he breakpoint triggers, F9 again on the line
continue (F5)

expected: Doesn't trigger again
actual: triggers again.

NOTE: Can still disable, delete when not debugging.
NOTE: secondary issue is that PC and BP symbols overlap, though I don't know of a solution for that

[Feature Request]: Support neovim

I'm ready to send a PR if you're fine with this.

The demo images are broken

README.md links to C-demo and Python-demo (I assume, gifs). The links for those demos are broken.

Using gdb/lldb commands instead of key mapping

Hello!

First of all thanks for awesome plugin.

Describe the bug
I prefer to use commands of debugger instead of key mapping. So, I'm tried to use console window for inputting some commands there. But some moments are annoyed me:

UI windows are not updated (window with source code doesn't change current position in the code and window with locals doesn't change values of variables). You can see it on the screenshot. Just compare output of console and values in the UI elements (Source window should show me current line on two lines below and value of a variable should be equal to 2 in the locals window)
After every input in the console, vim changes focus to window with source code and also, I have to write -exec before every command. I think it would be nice to have a vim variable which can tell to the plugin that I prefer to use debugger commands and it doesn't necessary to change focus from Console window to Source window. Also if this variable was set then it is probably not necessary to enter -exec before each command and just enter commands of debugger (lldb/gdb).

To Reproduce
List of steps to reproduce

Vimspector config file:

{
  "configurations": {
    "Run debug": {
      "adapter": "vscode-cpptools",
      "configuration": {
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/a.out",
        "cwd": "${workspaceRoot}",
        "externalConsole": false,
        "stopAtEntry": true,
        "MImode": "lldb"
      }
    }
  }
}

Cpp source file:

#include <iostream>

int main() {
    std::cout << "Hello world!" << std::endl;
    int a = 1;
    ++a;
    int& b = a;
    ++a;
    std::cout << "a: " << a << " b: " << b << std::endl;
    return 0;
}

Actual behaviour
I already described it in bug description section.

Vimspector log (~/.vimspector.log): vimspector.log

Environemnt

Output of vim --version

VIM - Vi IMproved 8.1 (2018 May 18, compiled Jun 11 2019 08:22:43)
macOS version
Included patches: 1-1517
Compiled by [email protected]
Huge version with MacVim GUI.  Features included (+) or not (-):
+acl               +file_in_path      +mouse_urxvt       -tcl
+arabic            +find_in_path      +mouse_xterm       +termguicolors
+autocmd           +float             +multi_byte        +terminal
+autochdir         +folding           +multi_lang        +terminfo
-autoservername    -footer            -mzscheme          +termresponse
+balloon_eval      +fork()            +netbeans_intg     +textobjects
+balloon_eval_term +fullscreen        +num64             +textprop
+browse            -gettext           +odbeditor         +timers
++builtin_terms    -hangul_input      +packages          +title
+byte_offset       +iconv             +path_extra        +toolbar
+channel           +insert_expand     +perl/dyn          +transparency
+cindent           +job               +persistent_undo   +user_commands
+clientserver      +jumplist          +postscript        +vartabs
+clipboard         +keymap            +printer           +vertsplit
+cmdline_compl     +lambda            +profile           +virtualedit
+cmdline_hist      +langmap           +python/dyn        +visual
+cmdline_info      +libcall           +python3/dyn       +visualextra
+comments          +linebreak         +quickfix          +viminfo
+conceal           +lispindent        +reltime           +vreplace
+cryptv            +listcmds          +rightleft         +wildignore
+cscope            +localmap          +ruby/dyn          +wildmenu
+cursorbind        +lua/dyn           +scrollbind        +windows
+cursorshape       +menu              +signs             +writebackup
+dialog_con_gui    +mksession         +smartindent       -X11
+diff              +modify_fname      -sound             -xfontset
+digraphs          +mouse             +spell             +xim
+dnd               +mouseshape        +startuptime       -xpm
-ebcdic            +mouse_dec         +statusline        -xsmp
+emacs_tags        -mouse_gpm         -sun_workshop      -xterm_clipboard
+eval              -mouse_jsbterm     +syntax            -xterm_save
+ex_extra          +mouse_netterm     +tag_binary
+extra_search      +mouse_sgr         -tag_old_static
-farsi             -mouse_sysmouse    -tag_any_white
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/Applications/MacVim.app/Contents/Resources/vim"
Compilation: clang -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X -DMACOS_X_DARWIN  -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1
Linking: clang   -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib -L. -fstack-protector-strong -L/usr/local/lib -L/usr/local/opt/libyaml/lib -L/usr/local/opt/openssl/lib -L/usr/local/opt/readline/lib  -L/usr/local/lib -o Vim -framework Cocoa -framework Carbon       -lm  -lncurses -liconv -framework AppKit   -fstack-protector  -L/System/Library/Perl/5.18/darwin-thread-multi-2level/CORE

Output of which vim:

/usr/local/bin/vim

Output of :py3 pass (is empty):

Operating system: macOS (10.14.5)

Java Support via coc.nvim

The Readme mentions, that java support could be gained by integrating something like ycmd. I would propose using coc.nvim for this instead. It has much better language support and even offers bundled language servers. The java extension for coc should already contain a working DAP Server. It is part of eclipse.jdt.ls.

[Feature Request]: Zero config for trivial projects

Is your feature request related to a problem? Please describe.
Configuring vimspector for the project isn't easy if you don't know the options for a given adapter. The READMe has some examples, but that's not easily accessible. VScode provides semantic completion (using json language server and son schema from package.json), but vimspector requires you just know its config or read the instructions n the website.

Describe the solution you'd like
Ideally, read package.json and integrate with YCM's json language server support (which doesn't exist) and its snippet completions (which also don't exist).

But for starters we could just have some UltiSnips snippets which cover the supported languages

Out of scope: snippets for snippet systems I don't use, support for other completion systems I don't use.

Describe alternatives you've considered
As above - maybe parse the package.json if it exists (e.g. for vscode-cpptools, vscode-python)

Breakpoints: Changing file contents moves signs but does not update breakpoint location

Describe the bug

When a breakpoint is set with no active debug session, the sign appears next to the line (OK). If you then insert lines or delete them, the Vim sign moves around with the line (great!), however, Vimspector doesn't know this has happened, and still thinks the breakpoint is on the (absolute) line number which the user specified, leading to strange results and unexpected breakpoints.

To Reproduce

Open some file
Go to a line
Press <F9>
Go up a line and delete it
Try and disbable the breakpoint, (press <F9>)

etc., including start debugging.

Expected behavior

Breakpoint is disabled, and/or striggers at the expected line.

Actual behaviour

Spurious breakpoint created, break on wrong line, etc.

NameError: name 'vim' is not defined when in neovim

Describe the bug
I am trying to setup Vimspector with Neovim, and I am getting this error when I call vimspector#Launch():

Error detected while processing function vimspector#internal#state#Reset[8]..provider#python3#Call:
line   18:
Error invoking 'python_execute' on channel 8 (python3-script-host):
Traceback (most recent call last):
  File "<string>", line 2, in <module>
NameError: name 'vim' is not defined
Error detected while processing function vimspector#Continue[1]..provider#python3#Call:
line   18:
Error invoking 'python_execute' on channel 8 (python3-script-host):
Traceback (most recent call last):
  File "<string>", line 1, in <module>
NameError: name '_vimspector_session' is not defined

My NeoVim has both python2 and 3 support. (pynvim installed)

To Reproduce
I followed this issue and added

Plug 'puremourning/vimspector', {'do': './install_gadget.py --enable-c --enable-python'}

to my init.vim.

When I :call vimspector#ToggleBreakpoint() or :call vimspector#Launch(), I would get the error listed above.

Vimspector config file:

{
  "configurations": {
    "<name>: Launch": {
      "adapter": "vscode-cpptools",
      "configuration": {
        "name": "<name>",
        "type": "cppdbg",
        "request": "launch",
        "program": "${workspaceRoot}/debug/neodm",
        "cwd": "${workspaceRoot}",
        "externalConsole": true,
        "stopAtEntry": true,
        "MIMode": "gdb"
      }
    },
    "<name>: Attach": {
      "adapter": "vscode-cpptools",
      "configuration": {
        "name": "<name>: Attach",
        "type": "cppdbg",
        "request": "attach",
        "program": "${workspaceRoot}/debug/neodm",
        "MIMode": "gdb"
      }
    }
  }
}

(~/.vimspector.log is empty)

Environemnt

Output of vim --version

NVIM v0.4.3
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O2 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unu
sed-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-s
trong -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/
build/neovim/src/build/config -I/build/neovim/src/neovim-0.4.3/src -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovi
m/src/build/include
Compiled by builduser

Features: +acl +iconv +tui

Output of which vim:

/usr/bin/vim (sym linked to /usr/bin/nvim)

Output of :py3 pass:

Operating system: and version
Up-to-date Arch Linux