{"id":13479789,"url":"https://github.com/puremourning/vimspector","last_synced_at":"2025-05-13T19:12:06.283Z","repository":{"id":37359135,"uuid":"134156823","full_name":"puremourning/vimspector","owner":"puremourning","description":"vimspector - A multi-language debugging system for Vim","archived":false,"fork":false,"pushed_at":"2025-04-24T09:31:16.000Z","size":5573,"stargazers_count":4204,"open_issues_count":39,"forks_count":176,"subscribers_count":37,"default_branch":"master","last_synced_at":"2025-04-25T22:43:50.644Z","etag":null,"topics":["cpp","debug-adapter-protocol","debugger","debugging","java","python","tcl","vim"],"latest_commit_sha":null,"homepage":"http://puremourning.github.io/vimspector-web","language":"Vim Script","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/puremourning.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":null,"code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":"support/bin/testecho","governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-05-20T14:19:41.000Z","updated_at":"2025-04-25T20:39:40.000Z","dependencies_parsed_at":"2023-02-16T15:45:51.039Z","dependency_job_id":"500436b3-6de9-4be9-9a29-12bfc076ecce","html_url":"https://github.com/puremourning/vimspector","commit_stats":{"total_commits":1520,"total_committers":83,"mean_commits":"18.313253012048193","dds":0.3203947368421053,"last_synced_commit":"d028fec66d7be66f7160882bd9d737c334a0c37e"},"previous_names":[],"tags_count":474,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puremourning%2Fvimspector","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puremourning%2Fvimspector/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puremourning%2Fvimspector/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/puremourning%2Fvimspector/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/puremourning","download_url":"https://codeload.github.com/puremourning/vimspector/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250907665,"owners_count":21506068,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["cpp","debug-adapter-protocol","debugger","debugging","java","python","tcl","vim"],"created_at":"2024-07-31T16:02:23.015Z","updated_at":"2025-04-25T22:44:11.249Z","avatar_url":"https://github.com/puremourning.png","language":"Vim Script","readme":"# vimspector - A multi language graphical debugger for Vim\n\nFor a tutorial and usage overview, take a look at the\n[Vimspector website][website].\n\nFor detailed explanation of the `.vimspector.json` format, see the\n[reference guide][vimspector-ref].\n\n[![Build](https://github.com/puremourning/vimspector/actions/workflows/build.yaml/badge.svg?branch=master)](https://github.com/puremourning/vimspector/actions/workflows/build.yaml) [![Matrix](https://img.shields.io/matrix/vimspector:matrix.org?label=matrix)](https://matrix.to/#/#vimspector_Lobby:gitter.im) [![Gitter](https://badges.gitter.im/vimspector/Lobby.svg)](https://gitter.im/vimspector/Lobby?utm_source=badge\u0026utm_medium=badge\u0026utm_campaign=pr-badge)\n\n\u003c!--ts--\u003e\n* [Features and Usage](#features-and-usage)\n   * [Supported debugging features](#supported-debugging-features)\n   * [Supported languages](#supported-languages)\n   * [Other languages](#other-languages)\n* [Installation](#installation)\n   * [Quick Start](#quick-start)\n      * [Method 1: Using a repo clone, Vim packages and select gadgets to be installed](#method-1-using-a-repo-clone-vim-packages-and-select-gadgets-to-be-installed)\n      * [Method 2: Using a plugin manager](#method-2-using-a-plugin-manager)\n   * [Dependencies](#dependencies)\n      * [Neovim limitations](#neovim-limitations)\n      * [Windows differences](#windows-differences)\n   * [Trying it out](#trying-it-out)\n   * [Installing the plugin](#installing-the-plugin)\n   * [Install some gadgets](#install-some-gadgets)\n      * [VimspectorInstall and VimspectorUpdate commands](#vimspectorinstall-and-vimspectorupdate-commands)\n      * [install_gadget.py](#install_gadgetpy)\n   * [Manual gadget installation](#manual-gadget-installation)\n      * [The gadget directory](#the-gadget-directory)\n   * [Upgrade](#upgrade)\n* [About](#about)\n   * [Background](#background)\n* [What Vimspector is not](#what-vimspector-is-not)\n   * [Status](#status)\n      * [Experimental](#experimental)\n   * [Motivation](#motivation)\n   * [License](#license)\n   * [Sponsorship](#sponsorship)\n* [Mappings](#mappings)\n   * [Visual Studio / VSCode](#visual-studio--vscode)\n   * [Human Mode](#human-mode)\n* [Usage and API](#usage-and-api)\n   * [Launch and attach by PID:](#launch-and-attach-by-pid)\n      * [Picking a PID](#picking-a-pid)\n      * [Launch with options](#launch-with-options)\n      * [Debug configuration selection](#debug-configuration-selection)\n      * [Get configurations](#get-configurations)\n   * [Breakpoints](#breakpoints)\n      * [Breakpoints Window](#breakpoints-window)\n      * [Line breakpoints](#line-breakpoints)\n      * [Conditional breakpoints and logpoints](#conditional-breakpoints-and-logpoints)\n      * [Exception breakpoints](#exception-breakpoints)\n      * [Data breakpoints](#data-breakpoints)\n      * [API Summary](#api-summary)\n      * [Instruction breakpoints](#instruction-breakpoints)\n      * [Clear breakpoints](#clear-breakpoints)\n      * [Run to Cursor](#run-to-cursor)\n      * [Go to current line](#go-to-current-line)\n      * [Save and restore](#save-and-restore)\n   * [Stepping](#stepping)\n   * [Variables and scopes](#variables-and-scopes)\n   * [Variable or selection hover evaluation](#variable-or-selection-hover-evaluation)\n   * [Watches](#watches)\n      * [Watch autocompletion](#watch-autocompletion)\n   * [Disassembly](#disassembly)\n   * [Dump memory](#dump-memory)\n   * [Stack Traces](#stack-traces)\n      * [Child sessions](#child-sessions)\n   * [Program Output](#program-output)\n      * [Console](#console)\n      * [Console autocompletion](#console-autocompletion)\n      * [Log View](#log-view)\n   * [Closing debugger](#closing-debugger)\n   * [Terminate debuggee](#terminate-debuggee)\n* [Multiple debugging sessions](#multiple-debugging-sessions)\n* [Debug profile configuration](#debug-profile-configuration)\n   * [C, C++, Rust, etc.](#c-c-rust-etc)\n      * [Data visualization / pretty printing](#data-visualization--pretty-printing)\n      * [C++ Remote debugging](#c-remote-debugging)\n      * [C++ Remote launch and attach](#c-remote-launch-and-attach)\n   * [Rust](#rust)\n   * [Jai](#jai)\n   * [Python](#python)\n      * [Python Remote Debugging](#python-remote-debugging)\n      * [Python Remote launch and attach](#python-remote-launch-and-attach)\n      * [Python 2](#python-2)\n   * [TCL](#tcl)\n   * [C♯](#c)\n   * [Go](#go)\n   * [PHP](#php)\n      * [Debug web application](#debug-web-application)\n      * [Debug cli application](#debug-cli-application)\n   * [JavaScript and TypeScript](#javascript-and-typescript)\n   * [Java](#java)\n      * [Hot code replace](#hot-code-replace)\n      * [Usage with YouCompleteMe](#usage-with-youcompleteme)\n      * [Other LSP clients](#other-lsp-clients)\n   * [Lua](#lua)\n   * [Other servers](#other-servers)\n* [Customisation](#customisation)\n   * [Changing the default signs](#changing-the-default-signs)\n   * [Sign priority](#sign-priority)\n   * [Presentation Hints](#presentation-hints)\n   * [Changing the default window sizes](#changing-the-default-window-sizes)\n   * [Changing the terminal size](#changing-the-terminal-size)\n   * [Custom mappings while debugging](#custom-mappings-while-debugging)\n   * [Pre-launch building strategies](#pre-launch-building-strategies)\n   * [Disabling the WinBar](#disabling-the-winbar)\n   * [Advanced UI customisation](#advanced-ui-customisation)\n   * [Customising the WinBar](#customising-the-winbar)\n   * [Example](#example)\n* [FAQ](#faq)\n\n\u003c!-- Created by https://github.com/ekalinin/github-markdown-toc --\u003e\n\u003c!-- Added by: ben, at: Thu 12 Dec 2024 15:40:32 GMT --\u003e\n\n\u003c!--te--\u003e\n\n# Features and Usage\n\nThe plugin is a capable Vim graphical debugger for multiple languages.\nIt's mostly tested for C++, Python and TCL, but in theory supports any\nlanguage that Visual Studio Code supports (but see caveats).\n\nThe [Vimspector website][website] has an overview of the UI, along with basic\ninstructions for configuration and setup.\n\nBut for now, here's a (rather old) screenshot of Vimspector debugging Vim:\n\n![vimspector-vim-screenshot](https://puremourning.github.io/vimspector-web/img/vimspector-overview.png)\n\nAnd a couple of brief demos:\n\n[![asciicast](https://asciinema.org/a/VmptWmFHTNLPfK3DVsrR2bv8S.svg)](https://asciinema.org/a/VmptWmFHTNLPfK3DVsrR2bv8S)\n\n[![asciicast](https://asciinema.org/a/1wZJSoCgs3AvjkhKwetJOJhDh.svg)](https://asciinema.org/a/1wZJSoCgs3AvjkhKwetJOJhDh)\n\n## Supported debugging features\n\n- flexible configuration syntax that can be checked in to source control\n- breakpoints (function, line and exception breakpoints)\n- instruction breakpoints\n- data breakpoints\n- conditional breakpoints (function, line)\n- step in/out/over/up, stop, restart\n- run to cursor\n- go to line (reset program counter to line)\n- launch and attach, including PID picker\n- remote launch, remote attach\n- locals and globals display\n- watch expressions with autocompletion\n- variable inspection tooltip on hover\n- disassembly view and step-by-instruction\n- set variable value in locals, watch and hover windows\n- call stack display and navigation\n- hierarchical variable value display popup (see `\u003cPlug\u003eVimspectorBalloonEval`)\n- interactive debug console with autocompletion\n- launch debuggee within Vim's embedded terminal\n- logging/stdout display\n- simple stable API for custom tooling (e.g. integrate with language server)\n- view hex dump of process memory\n- multiple independent debugging sessions (debug different apps in tabs)\n- multi-process (multi-session) debugging\n\n## Supported languages\n\nThe following table lists the languages that are \"built-in\" (along with their\nruntime dependencies). They are categorised by their level of support:\n\n* `Tested` : Fully supported, Vimspector regression tests cover them\n* `Supported` : Fully supported, frequently used and manually tested\n* `Experimental`: Working, but not frequently used and rarely tested\n* `Legacy`: No longer supported, please migrate your config\n* `Retired`: No longer included or supported.\n\n| Language(s)             | Status       | Switch (for `install_gadget.py`)    | Adapter (for `:VimspectorInstall`)   | Dependencies                                 |\n| --------------------    | -----------  | ----------------------------------  | ------------------------------------ | -------------------------------------------- |\n| C, C++, Rust, Jai, etc. | Tested       | `--all` or `--enable-c` (or cpp)    | vscode-cpptools                      | mono-core                                    |\n| C, C++, Rust, Jai, etc. | Tested       | `--enable-rust`, `--enable-c`, etc. | CodeLLDB                             | none                                         |\n| Python                  | Tested       | `--all` or `--enable-python`        | debugpy                              | Python 3                                     |\n| Go                      | Tested       | `--enable-go`                       | delve                                | Go 1.16+                                     |\n| TCL                     | Supported    | `--all` or `--enable-tcl`           | tclpro                               | TCL \u003e= 8.5 \u003c 9.0                                     |\n| Bourne Shell            | Supported    | `--all` or `--enable-bash`          | vscode-bash-debug                    | Bash v??                                     |\n| Lua                     | Tested       | `--all` or `--enable-lua`           | local-lua-debugger-vscode            | Node \u003e=12.13.0, Npm, Lua interpreter         |\n| Node.js                 | Supported    | `--force-enable-node`               | vscode-js-debug                      | Node \u003e= 18                                   |\n| Javascript              | Supported    | `--force-enable-chrome`             | debugger-for-chrome                  | Chrome                                       |\n| Javascript              | Supported    | `--force-enable-firefox`            | vscode-firefox-debug                 | Firefox                                      |\n| Java                    | Supported    | `--force-enable-java  `             | vscode-java-debug                    | Compatible LSP plugin (see [later](#java))   |\n| PHP                     | Experimental | `--force-enable-php`                | vscode-php-debug                     | Node, PHP, XDEBUG                            |\n| C# (dotnet core)        | Tested       | `--force-enable-csharp`             | netcoredbg                           | DotNet core                                  |\n| F#, VB, etc.            | Supported    | `--force-enable-[fsharp,vbnet]`     | netcoredbg                           | DotNet core                                  |\n| Go (legacy)             | Legacy       | `--enable-go`                       | vscode-go                            | Node, Go, [Delve][]                          |\n| Python 2                | Legacy       | `--force-enable-python2`            | debugpy-python2                      | Python 2.7                                   |\n\n## Other languages\n\nVimspector should work for any debug adapter that works in Visual Studio Code.\n\nTo use Vimspector with a language that's not \"built-in\", see this\n[wiki page](https://github.com/puremourning/vimspector/wiki/Additional-Language-Support).\n\n# Installation\n\n## Quick Start\n\nThere are 2 installation methods:\n\n* Using a repo clone and Vim packages\n* Using a plugin manager\n\n### Method 1: Using a repo clone, Vim packages and select gadgets to be installed\n\n1. [Check the dependencies](#dependencies)\n1. Install the plugin as a Vim package. See `:help packages`.\n2. Add `packadd! vimspector` to your `.vimrc`\n2. Install some 'gadgets' (debug adapters) - see [here for installation commands](#install-some-gadgets) and [select gadgets to install](#supported-languages)\n3. Configure your project's debug profiles (create `.vimspector.json`, or set\n   `g:vimspector_configurations`) - see the [reference guide][vimspector-ref]\n\n### Method 2: Using a plugin manager\n\n1. [Check the dependencies](#dependencies)\n1. See the plugin manager's docs and install the plugin\n   For Vundle, use:\n\n   ```vim\n   Plugin 'puremourning/vimspector'\n   ```\n\n2. Install some 'gadgets' (debug adapters) - see [here for installation commands](#install-some-gadgets) and [select gadgets to install](#supported-languages)\n3. Configure your project's debug profiles (create `.vimspector.json`, or set\n   `g:vimspector_configurations`) - see the [reference guide][vimspector-ref]\n\nThe following sections expand on the above brief overview.\n\n## Dependencies\n\nVimspector requires:\n\n* One of:\n  * Vim 8.2.4797 or later \"huge\" build compiled with Python 3.10 or later\n  * Neovim 0.8 with Python 3.10 or later\n* One of the following operating systems:\n  * Linux\n  * macOS Mojave or later\n  * Windows (experimental)\n\nWhich Linux versions? I only test on Ubuntu 20.04 and later and RHEL 7.\n\n### Neovim limitations\n\nNeovim doesn't implement mouse hover balloons. Instead there is the\n`\u003cPlug\u003eVimspectorBalloonEval` mapping. There is no default mapping for this, so\nI recommend something like this to get variable display in a popup:\n\n```viml\n\" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)\n\n\" for normal mode - the word under the cursor\nnmap \u003cLeader\u003edi \u003cPlug\u003eVimspectorBalloonEval\n\" for visual mode, the visually selected text\nxmap \u003cLeader\u003edi \u003cPlug\u003eVimspectorBalloonEval\n```\n\n### Windows differences\n\nThe following features are not implemented for Windows:\n\n* Tailing the vimspector log in the Output Window.\n\n## Trying it out\n\nIf you just want to try out vimspector without changing your vim config, there\nare example projects for a number of languages in `support/test`, including:\n\n* Python ([support/test/python/simple_python](support/test/python/simple_python))\n* Go ([support/test/go/hello_world](support/test/go/hello_world) and [support/test/go/name-starts-with-vowel](support/test/go/name-starts-with-vowel))\n* Nodejs ([support/test/node/simple](support/test/node/simple))\n* Chrome/Firefox ([support/test/web](support/test/web))\n* etc.\n\nTo test one of these out, cd to the directory and run:\n\n```\nvim -Nu /path/to/vimspector/tests/vimrc --cmd \"let g:vimspector_enable_mappings='HUMAN'\"\n```\n\nThen press `\u003cF5\u003e`.\n\nThere's also a C++ project in `tests/testdata/cpp/simple/` with a `Makefile`\nwhich can be used to check everything is working. This is used by the regression\ntests in CI so should always work, and is a good way to check if the problem is\nyour configuration rather than a bug.\n\n## Installing the plugin\n\n1. Clone the plugin\n\nThere are many Vim plugin managers, and I'm not going to state a particular\npreference, so if you choose to use one, follow the plugin manager's\ndocumentation. For example, for Vundle, use:\n\n```viml\nPlugin 'puremourning/vimspector'\n```\n\nIf you don't use a plugin manager already, install vimspector as a Vim package\nby cloning this repository into your package path, like this:\n\n```\n$ git clone https://github.com/puremourning/vimspector ~/.vim/pack/vimspector/opt/vimspector\n```\n\n2. Configure vimspector in your `.vimrc`, for example to enable the standard\n   mappings:\n\n```viml\nlet g:vimspector_enable_mappings = 'HUMAN'\n```\n\n3. Load vimspector at runtime. This can also be added to your `.vimrc` after\n   configuring vimspector:\n\n```\npackadd! vimspector\n```\n\nSee `support/doc/example_vimrc.vim` for a minimal example.\n\n## Install some gadgets\n\nVimspector is a generic client for Debug Adapters. Debug Adapters (referred to\nas 'gadgets' or 'adapters') are what actually do the work of talking to the real\ndebuggers.\n\nIn order for Vimspector to be useful, you need to have some adapters installed.\n\nThere are a few ways to do this:\n\n* Using `:VimspectorInstall \u003cadapter\u003e \u003cargs...\u003e` (use TAB `wildmenu` to see the\n  options, also accepts any `install_gadget.py` option)\n* Using `python3 install_gadget.py \u003cargs\u003e` (use `--help` to see all options)\n* Attempting to launch a debug configuration; if the configured adapter\n  can't be found, vimspector will suggest installing one.\n* Using `:VimspectorUpdate` to install the latest supported versions of the\n  gadgets.\n\nHere's a demo of doing some installs and an upgrade:\n\n[![asciicast](https://asciinema.org/a/Hfu4ZvuyTZun8THNen9FQbTay.svg)](https://asciinema.org/a/Hfu4ZvuyTZun8THNen9FQbTay)\n\nBoth `install_gadget.py` and `:VimspectorInstall` do the same set of things,\nthough the default behaviours are slightly different. For supported languages,\nthey will:\n\n* Download the relevant debug adapter at a version that's been tested from the\n  internet, either as a 'vsix' (Visual Studio plugin), or clone from GitHub. If\n  you're in a corporate environment and this is a problem, you may need to\n  install the gadgets manually.\n* Perform any necessary post-installation actions, such as:\n  * Building any binary components\n  * Ensuring scripts are executable, because the VSIX packages are usually\n    broken in this regard.\n  * Set up the `gadgetDir` symlinks for the platform.\n\nFor example, to install the tested debug adapter for a language, run:\n\n| To install                          | Script                                        | Command                                         |\n| ---                                 | ---                                           | ---                                             |\n| `\u003cadapter\u003e`                         |                                               | `:VimspectorInstall \u003cadapter\u003e`                  |\n| `\u003cadapter1\u003e`, `\u003cadapter2\u003e`, ...     |                                               | `:VimspectorInstall \u003cadapter1\u003e \u003cadapter2\u003e ...`  |\n| `\u003clanguage\u003e`                        | `./install_gadget.py --enable-\u003clanguage\u003e ...` | `:VimspectorInstall --enable-\u003clanguage\u003e ...`    |\n| Supported adapters                  | `./install_gadget.py --all`                   | `:VimspectorInstall --all`                      |\n| Supported adapters, but not TCL     | `./install_gadget.py --all --disable-tcl`     | `:VimspectorInstall --all --disable-tcl`        |\n| Supported and experimental adapters | `./install_gadget.py --all --force-all`       | `:VimspectorInstall --all`                      |\n| Adapter for specific debug config   |                                               | Suggested by Vimspector when starting debugging |\n\n### VimspectorInstall and VimspectorUpdate commands\n\n`:VimspectorInstall` runs `install_gadget.py` in the background with some of\nthe options defaulted.\n\n`:VimspectorUpdate` runs `install_gadget.py` to re-install (i.e. update) any\ngadgets already installed in your `.gadgets.json`.\n\nThe output is minimal, to see the full output add `--verbose` to the command, as\nin `:VimspectorInstall --verbose ...`  or `:VimspectorUpdate --verbose ...`.\n\nIf the installation is successful, the output window is closed (and the output\nlost forever). Use a `!` to keep it open (e.g. `:VimspectorInstall! --verbose\n--all` or `:VimspectorUpdate!` (etc.).\n\nIf you know in advance which gadgets you want to install, for example so that\nyou can reproduce your config from source control, you can set\n`g:vimspector_install_gadgets` to a list of gadgets. This will be used when:\n\n* Running `:VimspectorInstall` with no arguments, or\n* Running `:VimspectorUpdate`\n\nFor example:\n\n```viml\nlet g:vimspector_install_gadgets = [ 'debugpy', 'vscode-cpptools', 'CodeLLDB' ]\n```\n\n### install\\_gadget.py\n\nBy default `install_gadget.py` will overwrite your `.gadgets.json` with the set\nof adapters just installed, whereas `:VimspectorInstall` will _update_ it,\noverwriting only newly changed or installed adapters.\n\nIf you want to just add a new adapter using the script without destroying the\nexisting ones, add `--update-gadget-config`, as in:\n\n```bash\n$ ./install_gadget.py --enable-tcl\n$ ./install_gadget.py --enable-rust --update-gadget-config\n$ ./install_gadget.py --enable-java --update-gadget-config\n```\n\nIf you want to maintain `configurations` outside of the vimspector repository\n(this can be useful if you have custom gadgets or global configurations),\nyou can tell the installer to use a different basedir, then set\n`g:vimspector_base_dir` to point to that directory, for example:\n\n```bash\n$ ./install_gadget.py --basedir $HOME/.vim/vimspector-config --all --force-all\n```\n\nThen add this to your `.vimrc`:\n\n```viml\nlet g:vimspector_base_dir=expand( '$HOME/.vim/vimspector-config' )\n```\n\nWhen using `:VimspectorInstall`, the `g:vimspector_base_dir` setting is\nrespected unless `--basedir` is manually added (not recommended).\n\nSee `--help` for more info on the various options.\n\n## Manual gadget installation\n\nIf the language you want to debug is not in the supported list above, you can\nprobably still make it work, but it's more effort.\n\nYou essentially need to get a working installation of the debug adapter, find\nout how to start it, and configure that in an `adapters` entry in either your\n`.vimspector.json` or in `.gadgets.json` or in `g:vimspector_adapters`.\n\nThe simplest way in practice is to install or start Visual Studio Code and use\nits extension manager to install the relevant extension. You can then configure\nthe adapter manually in the `adapters` section of your `.vimspector.json` or in\na `gadgets.json` or in `g:vimspector_adapters`.\n\nPRs are always welcome to add supported languages (which roughly translates to\nupdating `python/vimspector/gadgets.py` and testing it).\n\n\n### The gadget directory\n\nVimspector uses the following directory by default to look for a file named\n`.gadgets.json`: `\u003c/path/to/vimspector\u003e/gadgets/\u003cos\u003e`.\n\nThis path is exposed as the vimspector _variable_ `${gadgetDir}`. This is useful\nfor configuring gadget command lines.\n\nWhere os is one of:\n\n* `macos`\n* `linux`\n* `windows` (though note: Windows is not supported)\n\nThe format is the same as `.vimspector.json`, but only the `adapters` key is\nused:\n\nExample:\n\n```json\n{\n  \"adapters\": {\n    \"lldb-dap\": {\n      \"variables\": {\n        \"LLVM\": {\n          \"shell\": \"brew --prefix llvm\"\n        }\n      },\n      \"attach\": {\n        \"pidProperty\": \"pid\",\n        \"pidSelect\": \"ask\"\n      },\n      \"command\": [\n        \"lldb-dap\"\n      ],\n      \"env\": {\n        \"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY\": \"YES\"\n      },\n      \"name\": \"lldb\"\n    },\n    \"vscode-cpptools\": {\n      \"attach\": {\n        \"pidProperty\": \"processId\",\n        \"pidSelect\": \"ask\"\n      },\n      \"command\": [\n        \"${gadgetDir}/vscode-cpptools/debugAdapters/bin/OpenDebugAD7\"\n      ],\n      \"name\": \"cppdbg\"\n    }\n  }\n}\n```\n\nThe gadget file is automatically written by `install_gadget.py` (or\n`:VimspectorInstall`).\n\nVimspector will also load any files matching:\n`\u003c/path/to/vimspector\u003e/gadgets/\u003cos\u003e/.gadgets.d/*.json`. These have the same\nformat as `.gadgets.json` but are not overwritten when running\n`install_gadget.py`.\n\n## Upgrade\n\nAfter updating the Vimspector code (either via `git pull` or whatever package\nmanager), run `:VimspectorUpdate` to update any already-installed gadgets.\n\n# About\n\n## Background\n\nThe motivation is that debugging in Vim is a pretty horrible experience,\nparticularly if you use multiple languages. With pyclewn no more and the\nbuilt-in termdebug plugin limited to gdb, I wanted to explore options.\n\nWhile Language Server Protocol is well known, the Debug Adapter Protocol is less\nwell known, but achieves a similar goal: language agnostic API abstracting\ndebuggers from clients.\n\nThe aim of this project is to provide a simple but effective debugging\nexperience in Vim for multiple languages, by leveraging the debug adapters that\nare being built for Visual Studio Code.\n\nThe ability to do remote debugging is a must. This is key to my workflow, so\nbaking it in to the debugging experience is a top bill goal for the project. So\nvimspector has first-class support for executing programs remotely and attaching\nto them. This support is unique to vimspector and on top of (complementary to)\nany such support in actual debug adapters.\n\n# What Vimspector is not\n\nVimspector 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.\n\nVimspector is not:\n\n* a debugger! It's just the UI and some glue.\n* fast. It's abstractions all the way down. If you want a fast, native debugger,\n  there are other options.\n* comprehensive. It's limited by DAP, and limited by my time. I implement the\n  features I think most users will need, not every feature possible.\n* for everyone. Vimspector intentionally provides a \"one size fits all\" UI and\n  approach. This means that it can only provide essential/basic debugging\n  features for a given language. This makes it convenient for everyday usage,\n  but not ideal for power users or those with very precise or specific\n  requirements. See [motivation](#motivation) for more info.\n\n## Status\n\nVimspector is a work in progress, and any feedback/contributions are more\nthan welcome.\n\nThe backlog can be [viewed on Trello](https://trello.com/b/yvAKK0rD/vimspector).\n\n### Experimental\n\nThe plugin is currently _experimental_. That means that any part of it\ncan (and probably will) change, including things like:\n\n- breaking changes to the configuration\n- keys, layout, functionality of the UI\n\nHowever, I commit to only doing this in the most extreme cases and to announce\nsuch changes on Gitter well in advance. There's nothing more annoying than stuff\njust breaking on you. I get that.\n\n## Motivation\n\nA message from the author about the motivation for this plugin:\n\n\u003e Many development environments have a built-in debugger. I spend an inordinate\n\u003e amount of my time in Vim. I do all my development in Vim and I have even\n\u003e customised my workflows for building code, running tests etc.\n\u003e\n\u003e For many years I have observed myself, friends and colleagues have been\n\u003e writing `printf`, `puts`, `print`, etc.  debugging statements in all sorts of\n\u003e files simply because there is no _easy_ way to run a debugger for _whatever_\n\u003e language we happen to be developing in.\n\u003e\n\u003e I truly believe that interactive, graphical debugging environments are the\n\u003e best way to understand and reason about both unfamiliar and familiar code, and\n\u003e that the lack of ready, simple access to a debugger is a huge hidden\n\u003e productivity hole for many.\n\u003e\n\u003e Don't get me wrong, I know there are literally millions of developers out\n\u003e there that are more than competent at developing without a graphical debugger,\n\u003e but I maintain that if they had the ability to _just press a key_ and jump\n\u003e into the debugger, it would be faster and more enjoyable that just cerebral\n\u003e code comprehension.\n\u003e\n\u003e I created Vimspector because I find changing tools frustrating. `gdb` for c++,\n\u003e `pdb` for python, etc. Each has its own syntax. Each its own lexicon. Each its\n\u003e own foibles.\n\u003e\n\u003e I designed the configuration system in such a way that the configuration can\n\u003e be committed to source control so that it _just works_ for any of your\n\u003e colleagues, friends, collaborators or complete strangers.\n\u003e\n\u003e I made remote debugging a first-class feature because that's a primary use\n\u003e case for me in my job.\n\u003e\n\u003e With Vimspector I can _just hit `\u003cF5\u003e`_ in all of the languages I develop in\n\u003e and debug locally or remotely using the exact same workflow, mappings and UI.\n\u003e I have integrated this with my Vim in such a way that I can hit a button and\n\u003e _run the test under the cursor in Vimspector_.  This kind of integration has\n\u003e massively improved my workflow and productivity.  It's even made the process\n\u003e of learning a new codebase... fun.\n\u003e\n\u003e \\- Ben Jackson, Creator.\n\n## License\n\n[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)\n\nCopyright © 2018 Ben Jackson\n\n## Sponsorship\n\nIf you like Vimspector so much that you're wiling to part with your hard-earned\ncash, please consider donating to one of the following charities, which are\nmeaningful to the author of Vimspector (in order of preference):\n\n* [Hector's Greyhound Rescue](http://hectorsgreyhoundrescue.org)\n* [Cancer Research UK](https://www.cancerresearchuk.org)\n* [ICCF Holland](https://iccf.nl)\n* Any charity of your choosing.\n\n# Mappings\n\nBy default, vimspector does not change any of your mappings. Mappings are very\npersonal and so you should work out what you like and use vim's powerful mapping\nfeatures to set your own mappings. To that end, Vimspector defines the following\n`\u003cPlug\u003e` mappings:\n\n| Mapping                                       | Function                                                            | API                                                               |\n| ---                                           | ---                                                                 | ---                                                               |\n| `\u003cPlug\u003eVimspectorContinue`                    | When debugging, continue. Otherwise start debugging.                | `vimspector#Continue()`                                           |\n| `\u003cPlug\u003eVimspectorStop`                        | Stop debugging.                                                     | `vimspector#Stop()`                                               |\n| `\u003cPlug\u003eVimspectorRestart`                      | Restart debugging with the same configuration.                      | `vimspector#Restart()`                                            |\n| `\u003cPlug\u003eVimspectorPause`                       | Pause debuggee.                                                     | `vimspector#Pause()`                                              |\n| `\u003cPlug\u003eVimspectorBreakpoints`                 | Show/hide the breakpoints window                                    | `vimspector#ListBreakpoints()`                                    |\n| `\u003cPlug\u003eVimspectorToggleBreakpoint`            | Toggle line breakpoint on the current line.                         | `vimspector#ToggleBreakpoint()`                                   |\n| `\u003cPlug\u003eVimspectorToggleConditionalBreakpoint` | Toggle conditional line breakpoint or logpoint on the current line. | `vimspector#ToggleBreakpoint( { trigger expr, hit count expr } )` |\n| `\u003cPlug\u003eVimspectorAddFunctionBreakpoint`       | Add a function breakpoint for the expression under cursor           | `vimspector#AddFunctionBreakpoint( '\u003ccexpr\u003e' )`                   |\n| `\u003cPlug\u003eVimspectorGoToCurrentLine`             | Reset the current program counter to the current line               | `vimspector#GoToCurrentLine()`                                    |\n| `\u003cPlug\u003eVimspectorRunToCursor`                 | Run to Cursor                                                       | `vimspector#RunToCursor()`                                        |\n| `\u003cPlug\u003eVimspectorStepOver`                    | Step Over                                                           | `vimspector#StepOver()`                                           |\n| `\u003cPlug\u003eVimspectorStepInto`                    | Step Into                                                           | `vimspector#StepInto()`                                           |\n| `\u003cPlug\u003eVimspectorStepOut`                     | Step out of current function scope                                  | `vimspector#StepOut()`                                            |\n| `\u003cPlug\u003eVimspectorDisassemble`                 | Show disassembly. Enable instruction stepping                       | `vimspector#ShowDisassembly()`                                    |\n| `\u003cPlug\u003eVimspectorUpFrame`                     | Move up a frame in the current call stack                           | `vimspector#UpFrame()`                                            |\n| `\u003cPlug\u003eVimspectorDownFrame`                   | Move down a frame in the current call stack                         | `vimspector#DownFrame()`                                          |\n| `\u003cPlug\u003eVimspectorJumpToNextBreakpoint`        | Move Cursor to the next breakpoint in current file                  | `vimspector#JumpToNextBreakpoint()`                               |\n| `\u003cPlug\u003eVimspectorJumpToPreviousBreakpoint`    | Move Cursor to the previous breakpoint in current file              | `vimspector#JumpToPreviousBreakpoint()`                           |\n| `\u003cPlug\u003eVimspectorJumpToProgramCounter`        | Move Cursor to the program counter in the current frame             | `vimspector#JumpToProgramCounter()`                               |\n| `\u003cPlug\u003eVimspectorBalloonEval`                 | Evaluate expression under cursor (or visual) in popup               | *internal*                                                        |\n\n\nThese map roughly 1-1 with the API functions below.\n\nFor example, if you want `\u003cF5\u003e` to start/continue debugging, add this to some\nappropriate place, such as your `vimrc` (hint: run `:e $MYVIMRC`).\n\n```viml\nnmap \u003cF5\u003e \u003cPlug\u003eVimspectorContinue\n```\n\nIn addition, many users probably want to only enable certain Vimspector mappings\nwhile debugging is active. This is also possible, though it requires writing\n[some vimscript](#custom-mappings-while-debugging).\n\nThat said, many people are familiar with particular debuggers, so the following\nmappings can be enabled by setting `g:vimspector_enable_mappings` to the\nspecified value.\n\n## Visual Studio / VSCode\n\nTo use Visual Studio-like mappings, add the following to your `vimrc` **before\nloading vimspector**:\n\n```viml\nlet g:vimspector_enable_mappings = 'VISUAL_STUDIO'\n```\n\n| Key             | Mapping                                 | Function\n| ---             | ---                                     | ---\n| `F5`            | `\u003cPlug\u003eVimspectorContinue`              | When debugging, continue. Otherwise start debugging.\n| `Shift F5`      | `\u003cPlug\u003eVimspectorStop`                  | Stop debugging.\n| `Ctrl Shift F5` | `\u003cPlug\u003eVimspectorRestart`               | Restart debugging with the same configuration.\n| `F6`            | `\u003cPlug\u003eVimspectorPause`                 | Pause debuggee.\n| `F8`            | `\u003cPlug\u003eVimspectorJumpToNextBreakpoint`  | Jump to next breakpoint in the current file.\n| `Shift F8`      | `\u003cPlug\u003eVimspectorJumpToPreviousBreakpoint` | Jump to previous breakpoint in the current file.\n| `F9`            | `\u003cPlug\u003eVimspectorToggleBreakpoint`      | Toggle line breakpoint on the current line.\n| `Shift F9`      | `\u003cPlug\u003eVimspectorAddFunctionBreakpoint` | Add a function breakpoint for the expression under cursor\n| `F10`           | `\u003cPlug\u003eVimspectorStepOver`              | Step Over\n| `Ctrl F10`      | `\u003cPlug\u003eVimspectorRunToCursor`           | Run to cursor*\n| `F11`           | `\u003cPlug\u003eVimspectorStepInto`              | Step Into\n| `Shift F11`     | `\u003cPlug\u003eVimspectorStepOut`               | Step out of current function scope\n| `Alt 8`         | `\u003cPlug\u003eVimspectorDisassemble`           | Show disassembly\n\n***NOTE: Some mappings, such as ctrl and F-keys may not work depending on your\nterminal, keyboard, windowing system and all sorts of other things.\nSee `:help modifyOtherKeys` and other sources. If you are unable to make this\nwork, just use the \"human mode\" mappings.***\n\n## Human Mode\n\nIf, like me, you only have 2 hands and 10 fingers, you probably don't like\nCtrl-Shift-F keys. Also, if you're running in a terminal, there's a real\npossibility of terminfo being wrong for shifted-F-keys, particularly if your\n`TERM` is `screen-256color`. If these issues (number of hands, `TERM` variables)\nare unfixable, try the following mappings, by adding the following **before\nloading vimspector**:\n\n```viml\nlet g:vimspector_enable_mappings = 'HUMAN'\n```\n\n| Key          | Mapping                                       | Function\n| ---          | ---                                           | ---\n| `F5`         | `\u003cPlug\u003eVimspectorContinue`                    | When debugging, continue. Otherwise start debugging.\n| `F3`         | `\u003cPlug\u003eVimspectorStop`                        | Stop debugging.\n| `F4`         | `\u003cPlug\u003eVimspectorRestart`                     | Restart debugging with the same configuration.\n| `F6`         | `\u003cPlug\u003eVimspectorPause`                       | Pause debuggee.\n| `F9`         | `\u003cPlug\u003eVimspectorToggleBreakpoint`            | Toggle line breakpoint on the current line.\n| `\u003cleader\u003eF9` | `\u003cPlug\u003eVimspectorToggleConditionalBreakpoint` | Toggle conditional line breakpoint or logpoint on the current line.\n| `F8`         | `\u003cPlug\u003eVimspectorAddFunctionBreakpoint`       | Add a function breakpoint for the expression under cursor\n| `\u003cleader\u003eF8` | `\u003cPlug\u003eVimspectorRunToCursor`                 | Run to Cursor\n| `F10`        | `\u003cPlug\u003eVimspectorStepOver`                    | Step Over\n| `F11`        | `\u003cPlug\u003eVimspectorStepInto`                    | Step Into\n| `F12`        | `\u003cPlug\u003eVimspectorStepOut`                     | Step out of current function scope\n\nIn addition, I recommend adding a mapping to `\u003cPlug\u003eVimspectorBalloonEval`, in\nnormal and visual modes, for example:\n\n```viml\n\" mnemonic 'di' = 'debug inspect' (pick your own, if you prefer!)\n\n\" for normal mode - the word under the cursor\nnmap \u003cLeader\u003edi \u003cPlug\u003eVimspectorBalloonEval\n\" for visual mode, the visually selected text\nxmap \u003cLeader\u003edi \u003cPlug\u003eVimspectorBalloonEval\n```\n\nYou may also wish to add mappings for navigating up/down the stack, toggling\nthe breakpoints window, and showing disassembly, for example:\n\n```viml\nnmap \u003cLocalLeader\u003e\u003cF11\u003e \u003cPlug\u003eVimspectorUpFrame\nnmap \u003cLocalLeader\u003e\u003cF12\u003e \u003cPlug\u003eVimspectorDownFrame\nnmap \u003cLocalLeader\u003eB     \u003cPlug\u003eVimspectorBreakpoints\nnmap \u003cLocalLeader\u003eD     \u003cPlug\u003eVimspectorDisassemble\n```\n\n# Usage and API\n\nThis section defines detailed usage instructions, organised by feature. For most\nusers, the [mappings](#mappings) section contains the most common commands and\ndefault usage. This section can be used as a reference to create your own\nmappings or custom behaviours.\n\nAll the below instructions assume a single debugging session. For details on how\nto debug multiple independent apps at the same time, see\n[multiple debugging sessions][#multiple-debugging-sessions].\n\n## Launch and attach by PID:\n\n* Create `.vimspector.json`. See [below](#supported-languages).\n* `:call vimspector#Launch()` and select a configuration.\n\n![debug session](https://puremourning.github.io/vimspector-web/img/vimspector-overview.png)\n\nLaunching a new session makes it the active\n[debugging session][#multiple-debugging-sessions].\n\n### Picking a PID\n\nIf the debug adapter configuration uses `pidProperty`, and you make an `attach`\nrequest, then you will be asked to enter a PID (process ID) to attach to.\n\nTo make this easier, Vimspector supplies a little utility for listing PIDs. It's\nlike a very very simple clone of `ps` but works on all the supported platforms.\nSee [its README](support/vimspector_process_list/README.md) for instructions on\nsetting it up.\n\nRun `go build` in the `support/vimspector_process_list` directory to set it\nup.\n\nIf Vimspector is able to find this app, it will try to list all processes owned\nby the current user by default.\n\nAlternatively (preferably), you can use a special form of variable expansion\ncalled `${PickProcess(\\\"binaryName\\\")}`. The version of this call will list all\nprocesses for the current user that match this binary name.\n\nFor example:\n\n```jsonc\n\"Attach\": {\n  \"adapter\": \"CodeLLDB\",\n  \"configuration\": {\n    \"request\": \"attach\",\n    \"program\": \"${workspaceRoot}/Jails\",\n    \"pid\": \"${PickProcess(\\\"jails\\\")}\"\n  }\n}\n```\n\nThis will list each matching processes, its parent process, start time and\nworking directory. It's looks something like this:\n\n```\nPID   PPID           CWD                                           START\n52218 52217 (Python) /Users/ben/.vim/bundle/lsp-examples/jai/Jails 2023-05-22 16:02:24\nEnter Process ID:\n```\n\nYou then enter the PID and hit `\u003cCR\u003e`.\n\nYou can even replace the process picker with your own function. If you define\nsome function and set `g:vimspector_custom_process_picker_func` to the name of\nthat function. It will be passed any arguments passed to the `PickProcess`\nexpansion function. It will also be used whenever a `pidProperty` is specified,\nso it must also handle no arguments (use `...` as the formal arguments\nfor the function, see `:help ...`).\n\nFor example, to use `fzf` along with the supplied `vimspector_process_list`:\n\n```viml\nfunction! CustomPickProcess( ... ) abort\n  let ps = $HOME .. '/.vim/bundle/vimspector/support/vimspector_process_list/vimspector_process_list'\n  \" a:0 is number of args\n  \" a:1 is the optional binary name\n  if a:0 \u003e 0\n    let ps .= ' ^' . a:1 . '$'\n  endif\n\n  let line_selected = fzf#run( {\n      \\ 'source': ps,\n      \\ 'options': '--header-lines=1  '\n      \\          . '--prompt=\"Select Process: \" '\n      \\ ,\n      \\\n      \\ } )[ 0 ]\n  if empty( line_selected)\n    return 0\n  endif\n  let pid = split( line_selected )[ 0 ]\n  return str2nr( pid )\nendfunction\n\n\nlet g:vimspector_custom_process_picker_func = 'CustomPickProcess'\n```\n\nOr to use `fzf` with the output of `ps`:\n\n```viml\nfunction! CustomPickProcess( ... ) abort\n  let ps = 'ps aux'\n\n  let line_selected = fzf#run( {\n      \\ 'source': ps,\n      \\ 'options': '--header-lines=1  '\n      \\          . '--prompt=\"Select Process: \" '\n      \\ ,\n      \\\n      \\ } )[ 0 ]\n  if empty( line_selected)\n    return 0\n  endif\n  let pid = split( line_selected )[ 0 ]\n  return str2nr( pid )\nendfunction\n\n\nlet g:vimspector_custom_process_picker_func = 'CustomPickProcess'\n```\n\n### Launch with options\n\nTo launch a specific debug configuration, or specify [replacement\nvariables][vimspector-ref-var] for the launch, you can use:\n\n* `:call vimspector#LaunchWithSettings( dict )`\n\nThe argument is a `dict` with the following keys:\n\n* `configuration`: (optional) Name of the debug configuration to launch\n* `\u003canything else\u003e`: (optional) Name of a variable to set\n\nThis allows for some integration and automation.  For example, if you have a\nconfiguration named `Run Test` that contains a [replacement\nvariable][vimspector-ref-var] named `${Test}` you could write a mapping which\nultimately executes:\n\n```viml\nvimspector#LaunchWithSettings( #{ configuration: 'Run Test'\n                                \\ Test: 'Name of the test' } )\n```\n\nThis would start the `Run Test` configuration with `${Test}` set to `'Name of\nthe test'` and Vimspector would _not_ prompt the user to enter or confirm these\nthings.\n\nSee [our YouCompleteMe integration guide](#usage-with-youcompleteme) for\nanother example where it can be used to specify the port to connect the [java\ndebugger](#java---partially-supported)\n\nTo launch with an ad-hoc config you can use:\n\n* `call vimspector#LaunchWithConfigurations( dict )`\n\nThe argument is a `dict` which is the `configurations` section of a .vimspector\nfile. Pass one configuration in and that will be selected as the one to run.\nFor example:\n\n```viml\n   let pid = \u003csome_expression\u003e\n   call vimspector#LaunchWithConfigurations({\n               \\  \"attach\": {\n               \\    \"adapter\": \"netcoredbg\",\n               \\    \"configuration\": {\n               \\      \"request\": \"attach\",\n               \\      \"processId\": pid\n               \\    }\n               \\  }\n               \\})\n```\n\nThis would launch the debugger and attach to the specified process without the need\nto have a local .vimspector file on disk.\nThe `${workspaceRoot}` variable will point to the parent folder of the file that is\ncurrently open in vim.\n\n### Debug configuration selection\n\nVimspector uses the following logic to choose a configuration to launch:\n\n1. If a configuration was specified in the launch options (as above), use that.\n2. Otherwise if there's only one configuration and it doesn't have `autoselect`\n   set to `false`, use that.\n3. Otherwise if there's exactly one configuration with `default` set to `true`\n   and without `autoselect` set to `false`, use that.\n4. Otherwise, prompt the user to select a configuration.\n\nSee [the reference guide][vimspector-ref-config-selection] for details.\n\n\n### Get configurations\n\n* Use `vimspector#GetConfigurations()` to get a list of configurations for the\n  filetype of the current buffer\n\nFor example, to get an array of configurations and fuzzy matching on the result\n```viml\n:call matchfuzzy(vimspector#GetConfigurations(), \"test::case_1\")\n```\n\n## Breakpoints\n\nSee the [mappings](#mappings) section for the default mappings for working with\nbreakpoints. This section describes the full API in vimscript functions.\n\nBreakpoints are associated with the current\n[debugging session][#multiple-debugging-sessions]. When switching between\nsessions, the breakpoint signs for the previous session are removed and the\nbreakpoints for the newly activated session are displayed. While it might be\nuseful to see breakpoints for all sessions, this can be very confusing.\n\n### Breakpoints Window\n\nUse `:VimspectorBreakpoints` or map something to `\u003cPlug\u003eVimspectorBreakpoints`\nto open the breakpoints view. From here you can list, jump to delete, add and\ntoggle breakpoints.\n\nI recommend a mapping like this to toggle the breakpoints window:\n\n```viml\nnmap \u003cLeader\u003edb \u003cPlug\u003eVimspectorBreakpoints\n```\n\nThe following mappings apply by default in the breakpoints window:\n\n* `t`, `\u003cF9\u003e` - toggle, i.e. enable/disable breakpoint\n* `T` - toggle, i.e. enable/disable ALL breakpoints\n* `dd`, `\u003cDel\u003e` - delete the current breakpoint\n* `cc`, `C` - edit the current breakpoint options\n* `i`, `a`, `o` - add a new line breakpoint\n* `I`, `A`, `O` - add a new function breakpoint\n* `\u003cEnter\u003e` or double-click - jump to the line breakpoint\n\nA WinBar is provided (where supported) too. This adds functions like\nsaving/restoring sessions, clearing all breakpoints, and resetting the exception\nbreakpoints options.\n\n### Line breakpoints\n\nThe simplest and most common form of breakpoint is a line breakpoint. Execution\nis paused when the specified line is executed.\n\nFor most debugging scenarios, users will just hit `\u003cF9\u003e` to create a line\nbreakpoint on the current line and `\u003cF5\u003e` to launch the application.\n\n### Conditional breakpoints and logpoints\n\nSome debug adapters support conditional breakpoints. Note that vimspector does\nnot tell you if the debugger doesn't support conditional breakpoints (yet). A\nconditional breakpoint is a breakpoint which only triggers if some expression\nevaluates to true, or has some other constraints met.\n\nSome of these functions above take a single optional argument which is a\ndictionary of options. The dictionary can have the following keys:\n\n* `condition`: An optional expression evaluated to determine if the breakpoint\n  should fire. Not supported by all debug adapters. For example, to break when\n  `abc` is `10`, enter something like `abc == 10`, depending on the language.\n* `hitCondition`: An optional expression evaluated to determine a number of\n  times the breakpoint should be ignored. Should (probably?) not be used in\n  combination with `condition`. Not supported by all debug adapters. For\n  example, to break on the 3rd time hitting this line, enter `3`.\n* `logMessage`: An optional string to make this breakpoint a \"logpoint\" instead.\n  When triggered, this message is printed to the console rather than\n  interrupting execution. You can embed expressions in braces `{like this}`, for\n  example `#{ logMessage: \"Iteration {i} or {num_entries / 2}\" }`\n\nIn each case expressions are evaluated by the debugger, so should be in\nwhatever dialect the debugger understands when evaluating expressions.\n\nWhen using the `\u003cleader\u003e\u003cF9\u003e` mapping, the user is prompted to enter these\nexpressions in a command line (with history).\n\n### Exception breakpoints\n\nException breakpoints typically fire when an exception is throw or other error\ncondition occurs. Depending on the debugger, when starting debugging, you may be\nasked a few questions about how to handle exceptions. These are \"exception\nbreakpoints\" and vimspector remembers your choices while Vim is still running.\n\nTypically you can accept the defaults (just keep pressing `\u003cCR\u003e`!) as most debug\nadapter defaults are sane, but if you want to break on, say `uncaught exception`\nthen answer `Y` to that (for example).\n\nYou can configure your choices in the `.vimspector.json`. See\n[the configuration guide][vimspector-ref-exception] for details on that.\n\n### Data breakpoints\n\nData breakpoints are not supported by all debug adapters. They are breakpoints\nwhich trigger when some memory is read or written. They can be created:\n\n- For a given variable in the variables window (`\u003cF9\u003e` on variable)\n- For a given child variable in the watches or variables windows \n  (`\u003cF9\u003e` on child variable)\n- For an arbitrary expression which evaluates to an address (`\u003cF9\u003e` in watch\n  window, not on any variable)\n\nWhen specifying an expression, you can also specify a size.\n\nIn general, if you hit `\u003cF9\u003e` (or whatever mapping you have) in the Variables or\nWatch window, you'll be adding a Data Breakpoint. If the context looks like a\nvariable, then Vimspector will ask the debug adapter to create a data breakpoint\non that variable expression. Otherwise, you'll be asked to enter an expression,\nor an address and a size, depending on the capabilities of the debugger.\n\nNOTE: Not all debug adapters support data breakpoints, and the ability to\nactually create them often depends on the hardware of the target.\n\n### API Summary\n\n***NOTE:*** Previously, ToggleBreakpoint would cycle between 3 states:\nenabled, disabled, deleted. Many users found the 'disabled' state was rarely\nuseful, so the behaviour has been changed. ToggleBreakpoint always creates or\ndeletes a breakpoint. If you wish to 'disable' breakpoints, use the\n[breakpoints window](#breakpoints-window) and 'toggle' (`t`) from there.\n\n* Use `vimspector#ToggleBreakpoint( { options dict } )` to set/delete\n  a line breakpoint. The argument is optional (see below).\n* Use `vimspector#AddFunctionBreakpoint( '\u003cname\u003e', { options dict} )`\n  to add a function breakpoint. The second argument is optional (see below).\n* Use `vimspector#SetLineBreakpoint( file_name, line_num, { options dict } )` to\n  set a breakpoint at a specific file/line. The last argument is optional\n  (see below)\n* Use `vimspector#ClearLineBreakpoint( file_name, line_num )` to\n  remove a breakpoint at a specific file/line\n* Use `vimspector#ClearBreakpoints()` to clear all breakpoints\n* Use `vimspector#ResetExceptionBreakpoints()` to clear the exception breakpoints\n  configuration and re-answer the various questions like \"Break on C++ Throw\"\n* Use `:VimspectorMkSession` and `:VimspectorLoadSession` to save and restore\n  breakpoints\n* `call vimspector#ListBreakpoints()` - toggle breakpoints window\n* `call vimspector#BreakpointsAsQuickFix()` - return the current set of\n  breakpoints in vim quickfix format\n* `call vimspector#AddDataBreakpoint()` - add a data breakpoint\n\nExamples:\n\n* `call vimspector#ToggleBreakpoint()` - toggle breakpoint on current line\n* `call vimspector#SetLineBreakpoint( 'some_file.py', 10 )` - set a breakpoint\n  on `some_filepy:10`\n* `call vimspector#AddFunctionBreakpoint( 'main' )` - add a function breakpoint\n  on the `main` function\n* `call vimspector#ToggleBreakpoint( { 'condition': 'i \u003e 5' } )` - add a\n  breakpoint on the current line that triggers only when `i \u003e 5` is `true`\n* `call vimspector#SetLineBreakpoint( 'some_file.py', 10, { 'condition': 'i \u003e 5' } )` - add a\n  breakpoint at `some_file.py:10` that triggers only when `i \u003e 5` is `true`\n* `call vimspector#ClearLineBreakpoint( 'some_file.py', 10 )` - delete the\n  breakpoint at `some_file.py:10`\n* `call vimspector#ClearBreakpoints()` - clear all breakpoints\n* `VimspectorMkSession` - create `.vimspector.session`\n* `VimspectorLoadSession` - read `.vimspector.session`\n* `VimspectorMkSession my_session_file` - create `my_session_file`\n* `VimspectorLoadSession my_session_file` - read `my_session_file`\n\n### Instruction breakpoints\n\n**NOTE**: Experimental feature, which may change significantly in future based\non user feedback.\n\nInstruction breakpoints can be added from the [disassembly window](#disassembly)\nin the same way that you add [line breakpoints](#line-breakpoints) in the code\nwindow. The same mappings and functions work for adding and toggling them. Where\nsupported by the debug adapter, you can even create logpoints and conditional\nbreakpoints this way.\n\nCurrently, instruction breakpoints are internally modelled as line breakpoints\nagainst the buffer containing the disassembly, but that may change in future, so\nplease don't rely on this.\n\nInstruction breakpoints are also visible from and can be deleted/disabled from\nthe [breakpoints window](#breakpoints-window).\n\nCurrently, instruction breakpoints are automatically cleared when the debug\nsession ends. The reason for this is that the addresses can't be guaranteed to\nbe valid for any other debug session. However, this may also change in future.\n\n### Clear breakpoints\n\nUse `vimspector#ClearBreakpoints()`\nto clear all breakpoints including the memory of exception breakpoint choices.\n\n### Run to Cursor\n\nUse `vimspector#RunToCursor` or `\u003cleader\u003e\u003cF8\u003e`: this creates a temporary\nbreakpoint on the current line, then continues execution, clearing the\nbreakpoint when it is hit.\n\n### Go to current line\n\nUse `vimspector#GoToCurrentLine()` or some mapping to\n`\u003cPlug\u003eVimspectorGoToCurrentLine` to jump the current execution to the line your\ncursor is currently on.\n\nWhere supported this can be useful to re-run sections of code or skip over\nthem entirely.\n\nIf there are multiple possible \"targets\" on the current line, you're prompted to\npick one.\n\n### Save and restore\n\nVimspector can save and restore breakpoints (and some other stuff) to a session\nfile. The following commands exist for that:\n\n* `VimspectorMkSession [file/dir name]` - save the current set of line breakpoints,\n  logpoints, conditional breakpoints, function breakpoints and exception\n  breakpoint filters to the supplied session file or the default file in the\n  supplied directory.\n* `VimspectorLoadSession [file/dir name]` - read breakpoints from the session\n  file supplied or the default file in the supplied directory and replace any\n  currently set breakpoints. Prior to loading, all current breakpoints are\n  cleared (as if `vimspector#ClearLineBreakpoints()` was called).\n\nIn both cases, the file/dir name argument is optional. By default, the file is\nnamed `.vimspector.session`, but this can be changed globally by setting\n`g:vimspector_session_file_name` to something else, or by manually specifying a\npath when calling the command. If you supply a directory, the default or\nconfigured session file name is read from or written to that directory.\nOtherwise, the file is read based on the currently open buffer or written to the\ncurrent working directory.\n\nAdvanced users may wish to automate the process of loading and saving, for\nexample by adding `VimEnter` and `VimLeave` autocommands. It's recommended in\nthat case to use `silent!` to avoid annoying errors if the file can't be read or\nwritten.\n\nThe simplest form of automation is to load the vimspector session whenever you\nstart vim with a session file. This is as simple as doing this:\n\n```\n$ echo silent VimspectorLoadSession \u003e Sessionx.vim\n```\n\nSee `:help mksession` for details of the `*x.vim` file. You can also do\nsomething like this using `SessionLoadPost`:\n\n```viml\nautocmd SessionLoadPost * silent! VimspectorLoadSession\n```\n\n## Stepping\n\n* Step in/out, finish, continue, pause etc. using the WinBar, or mappings.\n* Stepping is contextual. By default, stepping is statement granularity. But\n  if your cursor is in the [disassembly window](#disassembly), then stepping\n  defaults to instruction granularity.\n* If you really want to, the API is `vimspector#StepInto()` etc.. There are also\n  `vimspector#StepSOver()` and `vimspector#StepIOver()` etc. variants for\n  statement and instruction granularity respectively.\n\n![code window](https://puremourning.github.io/vimspector-web/img/vimspector-code-window.png)\n\n## Variables and scopes\n\n* Current scope shows values of locals.\n* Use `\u003cCR\u003e`, or double-click with left mouse to expand/collapse (+, -).\n* Set the value of the variable with `\u003cC-CR\u003e` (control + `\u003cCR\u003e`) or\n  `\u003cleader\u003e\u003cCR\u003e` (if `modifyOtherKeys` doesn't work for you)\n* View the type of the variable via mouse hover.\n* When changing the stack frame the locals window updates.\n* While paused, hover to see values.\n* Create a data breakpoint with `\u003cF9\u003e`.\n\n![locals window](https://puremourning.github.io/vimspector-web/img/vimspector-locals-window.png)\n\nScopes and variables are represented by the buffer `vimspector.Variables`.\n\nIf you prefer a more verbose display for variables and watches, then you can\n`let g:vimspector_variables_display_mode = 'full'`. By default only the name and\nvalue are displayed, with other data available from hovering the mouse or\ntriggering `\u003cPlug\u003eVimspectorBalloonEval` on the line containing the value in the\nvariables (or watches) window.\n\n## Variable or selection hover evaluation\n\nAll rules for `Variables and scopes` apply plus the following:\n\n* With mouse enabled, hover over a variable and get the value it evaluates to.\n  This applies to the variables and watches windows too, and allows you to view\n  the type of the value.\n* Use your mouse to perform a visual selection of an expression (e.g. `a + b`)\n  and get its result.\n* Make a normal mode (`nmap`) and visual mode (`xmap`) mapping to\n  `\u003cPlug\u003eVimspectorBalloonEval` to manually trigger the popup.\n  * Set the value of the variable with `\u003cC-CR\u003e` (control + `\u003cCR\u003e`) or\n    `\u003cleader\u003e\u003cCR\u003e` (if `modifyOtherKeys` doesn't work for you)\n  * Use regular navigation keys (`j`, `k`) to choose the current selection; `\u003cEsc\u003e`\n    (or leave the tooltip window) to close the tooltip.\n\n![variable eval hover](https://puremourning.github.io/vimspector-web/img/vimspector-variable-eval-hover.png)\n\nYou can disable automatic hovering popup by settings\n`g:vimspector_enable_auto_hover=0` before starting the debug session. You can\nthen map something to `\u003cPlug\u003eVimspectorBalloonEval` and trigger it manually.\n\n## Watches\n\nThe watch window is used to inspect variables and expressions. Expressions are\nevaluated in the selected stack frame which is \"focussed\"\n\nThe watches window is a prompt buffer, where that's available. Enter insert mode\nto add a new watch expression.\n\n* Add watches to the variables window by entering insert mode and\n  typing the expression. Commit with `\u003cCR\u003e`.\n* Alternatively, use `:VimspectorWatch \u003cexpression\u003e`. Tab-completion for\n  expression is available in some debug adapters.\n* View the type of the variable via mouse hover.\n* Expand result with `\u003cCR\u003e`, or double-click with left mouse.\n* Set the value of the variable with `\u003cC-CR\u003e` (control + `\u003cCR\u003e`) or\n  `\u003cleader\u003e\u003cCR\u003e` (if `modifyOtherKeys` doesn't work for you)\n* Delete with `\u003cDEL\u003e`.\n* Create a data breakpoint with `\u003cF9\u003e`.\n\n![watch window](https://puremourning.github.io/vimspector-web/img/vimspector-watch-window.png)\n\nThe watches are represented by the buffer `vimspector.Watches`.\n\nIf you prefer a more verbose display for variables and watches, then you can\n`let g:vimspector_variables_display_mode = 'full'`. By default only the name and\nvalue are displayed, with other data available from hovering the mouse or\ntriggering `\u003cPlug\u003eVimspectorBalloonEval` on the line containing the value in the\nvariables (or watches) window.\n\nYou can disable automatic hovering popup by settings\n`g:vimspector_enable_auto_hover=0` before starting the debug session. You can\nthen map something to `\u003cPlug\u003eVimspectorBalloonEval` and trigger it manually.\n\n### Watch autocompletion\n\nThe watch prompt buffer has its `omnifunc` set to a function that will\ncalculate completion for the current expression. This is trivially used with\n`\u003cCtrl-x\u003e\u003cCtrl-o\u003e` (see `:help ins-completion`), or integrated with your\nfavourite completion system. The filetype in the buffer is set to\n`VimspectorPrompt`.\n\nFor YouCompleteMe, the following config works well:\n\n```viml\nlet g:ycm_semantic_triggers =  {\n  \\   'VimspectorPrompt': [ '.', '-\u003e', ':', '\u003c' ]\n}\n```\n\n## Disassembly\n\n* Display disassembly around current PC\n* Step over/into/out by instruction (contextually, or using the WinBar)\n* `:VimspectorDisassemble`, `vimspector#ShowDisassembly()` or\n  `\u003cPlug\u003eVimspectorDisassemble`\n\n[![Demo](https://asciinema.org/a/esEncAxP45CJmo8Em1sQtxRYe.svg)](https://asciinema.org/a/esEncAxP45CJmo8Em1sQtxRYe)\n\nSome debug adapters (few!) support disassembly. The way this works in DAP is a\nlittle weird, but in practice vimspector will ask to disassemble a number of\ninstructions around the current stack frame's PC. This is then shown in a window\nwith a WinBar similar to the Code window, but with instruction stepping\ngranularity. There's a sign for the current instruction and the syntax\nhighlighting defaults to \"asm\" which mostly works ok for x86 and ARM.\n\n![disassembly-view](https://user-images.githubusercontent.com/10584846/194766584-d798c96b-6e4e-4914-9d4a-991c219f78d0.png)\n\nAs mentioned above, when your current window is the disassembly windows and you\nuse the default \"step\" commands (e.g. `\u003cF10\u003e`), the stepping is automatically\nchanged to per-instruction rather than per statement.\n\nEach time the process stops, vimspector requests about 2 windows full of\ninstructions around the current PC. To see more, you can scroll the window.\nVimspector will page in an extra screenful of instructions when the window\nscrolls to the top or near the bottom. This isn't perfect. Sometimes you have to\nscroll a bit more to make it page in (e.g. ctrl-e ctrl-y at the top).\nThis is not ideal, and may be improved in future.\n\nYou can control the initial height of the disassembly window with\n`let g:vimspector_disassembly_height = 10` (or whatever number of lines).\n\nThe filetype (and syntax) of the buffers in the disassembly window is\n`vimspector-disassembly`. You can use `FileType` autocommands to customise\nthings like the syntax highlighting.\n\n***NOTE***: This feature is experimental and may change in any way based on user\nfeedback.\n\n## Dump memory\n\nSome debug adapters provide a way to dump process memory associated with\nvariables. This can be done from the Variables and Watches windows with:\n\n* The WinBar option \"Dump\"\n* `\u003cleader\u003em` mapping (by default, can be customised)\n* `vimspector#ReadMemory()` function\n\nOn doing this, you're asked to enter a number of bytes to read (from the\nlocation associated with the current cursor line) and an offset from that\nlocation. A new buffer is displayed in the Code Window containing a memory dump\nin hex and ascii, similar to the output of `xxd`.\n\n***NOTE***: This feature is experimental and may change in any way based on user\nfeedback.\n\n## Stack Traces\n\nThe stack trace window shows the state of each program thread. Threads which\nare stopped can be expanded to show the stack trace of that thread.\n\nOften, but not always, all threads are stopped when a breakpoint is hit. The\nstatus of a thread is show in parentheses after the thread's name. Where\nsupported by the underlying debugger, threads can be paused and continued\nindividually from within the Stack Trace window.\n\nA particular thread, highlighted with the `CursorLine` highlight group is the\n\"focussed\" thread. This is the thread that receives commands like \"Step In\",\n\"Step Out\", \"Continue\" and \"Pause\" in the code window. The focussed thread can\nbe changed manually to \"switch to\" that thread.\n\n* Use `\u003cCR\u003e`, or double-click with left mouse to expand/collapse a thread stack\n  trace, or use the WinBar button.\n* Use `\u003cCR\u003e`, or double-click with left mouse on a stack frame to jump to it.\n* Use the WinBar or `vimspector#PauseContinueThread()` to individually pause or\n  continue the selected thread.\n* Use the \"Focus\" WinBar button, `\u003cleader\u003e\u003cCR\u003e` or `vimspector#SetCurrentThread()`\n  to set the \"focussed\" thread to the currently selected one. If the selected\n  line is a stack frame, set the focussed thread to the thread of that frame and\n  jump to that frame in the code window.\n* The current frame when a breakpoint is hit or if manual jumping is also\n  highlighted.\n\n![stack trace](https://puremourning.github.io/vimspector-web/img/vimspector-callstack-window.png)\n\nThe stack trace is represented by the buffer `vimspector.StackTrace`.\n\n### Child sessions\n\nIf there are child debug sessions, such as where the debugee\nlaunches child processes and the debug adapter supports multi-session\ndebugging, then each session's threads are shown separately. The currently\nactive session is the one that is highlighted as the currently active\nthread/stack frame. To switch control to a different session, focus a thread\nwithin that session.\n\n![multiple sessions](https://user-images.githubusercontent.com/10584846/232473234-666d1a77-81f2-40d5-bc65-ebab774888ce.png)\n\nNote: This refers to sessions created as children of an existing session, and is\nnot to be confused with\n[multiple (parent) debugging sessions][#multiple-debugging-sessions].\n\n## Program Output\n\n* In the outputs window, use the WinBar to select the output channel.\n* Alternatively, use `:VimspectorShowOutput \u003ccategory\u003e`. Use command-line\n  completion to see the categories.\n* The debuggee prints to the stdout channel.\n* Other channels may be useful for debugging.\n\n![output window](https://puremourning.github.io/vimspector-web/img/vimspector-output-window.png)\n\nIf the output window is closed, a new one can be opened with\n`:VimspectorShowOutput \u003ccategory\u003e` (use tab-completion - `wildmenu` to see the\noptions).\n\n### Console\n\nThe console window is a prompt buffer, where that's available, and can be used\nas an interactive CLI for the debug adapter. Support for this varies amongst\nadapters.\n\n* Enter insert mode to enter a command to evaluate.\n* Alternatively, `:VimspectorEval \u003cexpression\u003e`. Completion is available with\n  some debug adapters.\n* Commit the request with `\u003cCR\u003e`\n* The request and subsequent result are printed.\n\nNOTE: See also [Watches](#watches) above.\n\nIf the output window is closed, a new one can be opened with\n`:VimspectorShowOutput Console`.\n\n### Console autocompletion\n\nThe console prompt buffer has its `omnifunc` set to a function that will\ncalculate completion for the current command/expression. This is trivially used\nwith `\u003cCtrl-x\u003e\u003cCtrl-o\u003e` (see `:help ins-completion`), or integrated with your\nfavourite completion system. The filetype in the buffer is set to\n`VimspectorPrompt`.\n\nFor YouCompleteMe, the following config works well:\n\n```viml\nlet g:ycm_semantic_triggers =  {\n  \\   'VimspectorPrompt': [ '.', '-\u003e', ':', '\u003c' ]\n}\n```\n\n### Log View\n\nThe Vimspector log file contains a full trace of the communication between\nVimspector and the debug adapter. This is the primary source of diagnostic\ninformation when something goes wrong that's not a Vim traceback.\n\nIf you just want to see the Vimspector log file, use `:VimspectorToggleLog`,\nwhich will tail it in a little window (doesn't work on Windows).\n\nYou can see some debugging info with `:VimspectorDebugInfo`\n\n## Closing debugger\n\nTo close the debugger, use:\n\n* `Reset` WinBar button\n* `:VimspectorReset` when the WinBar is not available.\n* `call vimspector#Reset()`\n\n\n## Terminate debuggee\n\nIf the debuggee is still running when stopping or resetting, then some debug\nadapters allow you to specify what should happen to it when finishing debugging.\nTypically, the default behaviour is sensible, and this is what happens most of\nthe time. These are the defaults according to DAP:\n\n* If the request was 'launch': terminate the debuggee\n* If the request was 'attach': don't terminate the debuggee\n\nSome debug adapters allow you to choose what to do when disconnecting. If you\nwish to control this behaviour, use `:VimspectorReset` or call\n`vimspector#Reset( { 'interactive': v:true } )`. If the debug adapter offers a\nchoice as to whether or not to terminate the debuggee, you will be prompted to\nchoose. The same applies for `vimspector#Stop()` which can take an argument:\n`vimspector#Stop( { 'interactive': v:true } )`.\n\n# Multiple debugging sessions\n\n**NOTE**: This feature is _experimental_ and any part of it may change in\nresponse to user feedback.\n\nVimspector supports starting an arbitrary number of debug sessions. Each session\nis associated with an individual UI tab. Typically, you only debug a single app\nand so don't need to think about this, but this advanced feature can be useful\nif you need to simultaneously debug multiple, independent applications, or\nmultiple independent instances of your application.\n\nAt any time there is a single \"active\" root session. Breakpoints are associated\nwith the current session, and all UI and API commands are applied to the\ncurrently active session.\n\nWhen switching between root sessions, the breakpoint signs for the previous\nsession are removed and the breakpoints for the newly activated session are\ndisplayed.  While it might be useful to see breakpoints for all sessions, this\ncan be very confusing.\n\nA typical workflow might be:\n\n1. Start debugging a server app (e.g. `:edit server.cc` then `\u003cF5\u003e`). This\n   starts a debug session named after the configuration selected. You could\n   rename it `:VimspectorRenameSession server`.\n2. Open the client code in a new tab (e.g. `:tabedit client.cc`)\n3. Instantiate and make active a new debugging session and name it `client`:\n   `:VimspectorNewSession client` (`client` is now the active session).\n4. Add a breakpoint in the `client` session and start debugging with `\u003cF5\u003e`.\n\nYou now have 2 vimspector tabs. Intuitively, switching to a particular tab will\nmake its session active. You can also manually switch the active session with\n`:VimspectorSwitchToSession \u003cname\u003e`.\n\nSo, in summary you have the following facilities:\n\n* `VimspectorNewSession \u003cname\u003e`\n  This creates a new session and makes it active. Optional name is used\n  in place of the generated one when starting a launch.\n* Switching to a specific debug tab makes that session active. This is\n  intuitive and probably the most common way to work with this.\n* Switching manually using `VimspectorSwitchToSession \u003ctab complete\u003e`.\n* Name/Rename session with `VimspectorRenameSession \u003cnew name\u003e`\n* Root-level sessions are never 'destroyed' but you can manually destroy\n  them (if you're brave) using `VimspectorDestroySession \u003cname\u003e`. You\n  can't destroy a running/active session.\n* `vimspector#GetSessionName()` useful for putting in a statusline. There's also\n  `vimspector#GetSessionID()` for techies.\n\nHere's an example of how you can display the current session name in the\n`statusline` (see `:help statusline`, or the documentation for your fancy status\nline plugin).\n\n```viml\nfunction! StlVimspectorSession()\n  \" Only include in buffers containing actual files\n  if !empty( \u0026buftype )\n    return ''\n  endif\n\n  \" Abort if vimspector not loaded\n  if !exists( '*vimspector#GetSessionName' ) ||\n        \\ !exists( '*vimspector#GetSessionID' )\n    return ''\n  endif\n\n  return vimspector#GetSessionName()\n        \\ .. ' ('\n        \\ .. vimspector#GetSessionID()\n        \\ .. ')'\nendfunction\n\n\" ... existing statusline stuff\n\" set statusline=...\n\" Show the vimspector active session name (max 20 chars) if there is onw.\nset statusline+=%(\\ %.20{StlVimspectorSession()}\\ %)\n```\n\n# Debug profile configuration\n\nFor an introduction to the configuration of `.vimspector.json`, take a look at\nthe Getting Started section of the [Vimspector website][website].\n\nFor a full explanation, including how to use variables, substitutions and how to\nspecify exception breakpoints, see [the docs][vimspector-ref].\n\nThe JSON configuration file allows C-style comments:\n\n* `// comment to end of line ...`\n* `/* inline comment ... */`\n\nCurrently tested with the following debug adapters.\n\n## C, C++, Rust, etc.\n\n* Recommended: [CodeLLDB](#rust)\n* [vscode-cpptools](https://github.com/Microsoft/vscode-cpptools)\n* [lldb-dap](https://marketplace.visualstudio.com/items?itemName=llvm-vs-code-extensions.lldb-dap)\n* I *strongly* recommend using [CodeLLDB](#rust) over cpptools for almost all\nprojects. It's really excellent, has fewer dependencies and doesn't open console\napps in another Terminal window.\n\n\nExample `.vimspector.json` (works with both `vscode-cpptools` and `lldb-dap`.\nFor `lldb-dap` replace the name of the adapter with `lldb-dap`:\n\n* vscode-cpptools Linux/MacOS:\n\n```json\n{\n  \"configurations\": {\n    \"Launch\": {\n      \"adapter\": \"vscode-cpptools\",\n      \"filetypes\": [ \"cpp\", \"c\", \"objc\", \"rust\" ], // optional\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"\u003cpath to binary\u003e\",\n        \"args\": [ ... ],\n        \"cwd\": \"\u003cworking directory\u003e\",\n        \"environment\": [ ... ],\n        \"externalConsole\": true,\n        \"MIMode\": \"\u003clldb or gdb\u003e\"\n      }\n    },\n    \"Attach\": {\n      \"adapter\": \"vscode-cpptools\",\n      \"filetypes\": [ \"cpp\", \"c\", \"objc\", \"rust\" ], // optional\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"program\": \"\u003cpath to binary\u003e\",\n        \"MIMode\": \"\u003clldb or gdb\u003e\"\n      }\n    }\n    // ...\n  }\n}\n```\n\n* vscode-cpptools Windows\n\n***NOTE FOR WINDOWS USERS:*** You need to install `gdb.exe`. I recommend using\n`scoop install gdb`. Vimspector cannot use the visual studio debugger due to\nlicensing.\n\n```json\n{\n  \"configurations\": {\n    \"Launch\": {\n      \"adapter\": \"vscode-cpptools\",\n      \"filetypes\": [ \"cpp\", \"c\", \"objc\", \"rust\" ], // optional\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"\u003cpath to binary\u003e\",\n        \"stopAtEntry\": true\n      }\n    }\n  }\n}\n```\n\n* `lldb-dap`\n\n```json\n\n    \"lldb-dap\": {\n      \"adapter\": {\n          \"command\": [\n            // TODO: Replace this with the path to your installation of lldb\n            \"/opt/homebrew/Cellar/llvm/bin/lldb-dap\"\n          ],\n          \"name\": \"lldb\"\n      },\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${workspaceRoot}/${fileBasenameNoExtension}\",\n        \"args\": [\n            \"*${args}\"\n        ],\n        \"stopOnEntry\": true,\n        \"runInTerminal\": true,\n        \"cwd\": \"${workspaceRoot}\"\n      }\n    }\n```\n\n### Data visualization / pretty printing\n\nDepending on the backend you need to enable pretty printing of complex types\nmanually.\n\n* LLDB: Pretty printing is enabled by default\n\n* GDB: To enable gdb pretty printers, consider the snippet below.\n  It is not enough to have `set print pretty on` in your .gdbinit!\n\n```json\n{\n  \"configurations\": {\n    \"Launch\": {\n      \"adapter\": \"vscode-cpptools\",\n      \"filetypes\": [ \"cpp\", \"c\", \"objc\", \"rust\" ], // optional\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"\u003cpath to binary\u003e\",\n        // ...\n        \"MIMode\": \"gdb\",\n        \"setupCommands\": [\n          {\n            \"description\": \"Enable pretty-printing for gdb\",\n            \"text\": \"-enable-pretty-printing\",\n            \"ignoreFailures\": true\n          }\n        ]\n      }\n    }\n  }\n}\n```\n\n### C++ Remote debugging\n\nThe cpptools documentation describes how to attach cpptools to gdbserver using\n`miDebuggerAddress`. Note that when doing this you should use the\n`\"request\": \"attach\"`.\n\n### C++ Remote launch and attach\n\nIf you're feeling fancy, check out the [reference guide][remote-debugging] for\nan example of getting Vimspector to remotely launch and attach.\n\n* CodeLLDB (MacOS)\n\nCodeLLDB is superior to vscode-cpptools in a number of ways.\n\nSee [Rust](#rust).\n\n* lldb-dap (MacOS)\n\nAn alternative is to to use `lldb-dap`, which comes with llvm.  Here's how:\n\n* Install llvm (e.g. with HomeBrew: `brew install llvm`)\n* Create a file named\n  `/path/to/vimspector/gadgets/macos/.gadgets.d/lldb-dap.json`:\n\n```json\n{\n  \"adapters\": {\n    \"lldb-dap\": {\n      \"variables\": {\n        \"LLVM\": {\n          \"shell\": \"brew --prefix llvm\"\n        }\n      },\n      \"attach\": {\n        \"pidProperty\": \"pid\",\n        \"pidSelect\": \"ask\"\n      },\n      \"command\": [\n        \"${LLVM}/bin/lldb-dap\"\n      ],\n      \"env\": {\n        \"LLDB_LAUNCH_FLAG_LAUNCH_IN_TTY\": \"YES\"\n      },\n      \"name\": \"lldb\"\n    }\n  }\n}\n```\n\n## Rust\n\nRust is supported with any gdb/lldb-based debugger. So it works fine with\n`vscode-cpptools` and `lldb-dap` above. However, support for rust is best in\n[`CodeLLDB`](https://github.com/vadimcn/vscode-lldb#features).\n\n* `./install_gadget.py --enable-rust` or `:VimspectorInstall CodeLLDB`\n* Example: `support/test/rust/vimspector_test`\n\n```json\n{\n  \"configurations\": {\n    \"launch\": {\n      \"adapter\": \"CodeLLDB\",\n      \"filetypes\": [ \"rust\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${workspaceRoot}/target/debug/vimspector_test\",\n        \"sourceLanguages\": [ \"rust\" ]\n      }\n    },\n    \"attach\": {\n      \"adapter\": \"CodeLLDB\",\n      \"filetypes\": [ \"rust\", \"c\", \"cpp\", \"jai\" ],\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"program\": \"${workspaceRoot}/${fileBasenameNoExtension}\",\n        \"PID\": \"${PID}\",\n        \"sourceLanguages\": [ \"rust\" ]\n      }\n    }\n  }\n}\n```\n\n* Docs: https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md\n* ***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\n\n\n1. To use the [\"custom\" launch](https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#custom-launch), you can't use `\"request\": \"custom\"` - this is invalid. Instead use `\"request\": \"launch\", \"custom\": true`. Because [reasons](https://github.com/vadimcn/vscode-lldb/blob/master/extension/main.ts#L397-L401)\n2. All the integration with `cargo` is done in the vscode javascript madness, so is not supported.\n3. The stuff about [remote agents](https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#connecting-to-a-gdbserver-style-agent) uses `\"request\": custom`; see the point about \"custom\" launch above\n4. 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.\n\n## Jai\n\nJai debugging works fine with any of the other native debuggers. I recommend [CodeLLDB](#rust), but cpptools also works.\n\nExample:\n\n```jsonc\n{\n  \"$schema\": \"https://puremourning.github.io/vimspector/schema/vimspector.schema.json\",\n  \"adapters\": {\n    \"gdb-with-build\": {\n      \"extends\": \"vscode-cpptools\",\n      \"variables\": {\n        \"buildme\": {\n          \"shell\": \"jai ${workspaceRoot}/build.jai\"\n        }\n      }\n    },\n    \"codelldb-with-build\": {\n      \"extends\": \"CodeLLDB\",\n      \"variables\": {\n        \"buildme\": {\n          \"shell\": \"jai ${workspaceRoot}/build.jai\"\n        }\n      }\n    }\n  },\n  \"configurations\": {\n    \"Run - gdb\": {\n      \"adapter\": \"gdb-with-build\",\n      \"filetypes\": [ \"jai\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${workspaceRoot}/${binaryName}\",\n        \"args\": [ \"*${args}\" ],\n        \"stopAtEntry\": true,\n        \"stopOnEntry\": true\n      }\n    },\n    \"Run - lldb\": {\n      \"extends\": \"Run - gdb\",\n      \"filetypes\": [ \"jai\" ],\n      \"adapter\": \"codelldb-with-build\"\n    },\n    \"Attach - gdb\": {\n      \"adapter\": \"vscode-cpptools\",\n      \"filetypes\": [ \"jai\" ],\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"program\": \"${workspaceRoot}/${binaryName}\",\n        \"processId\": \"${PID}\"\n      }\n    },\n    \"Attach - lldb\": {\n      \"extends\": \"Attach - gdb\",\n      \"filetypes\": [ \"jai\" ],\n      \"adapter\": \"CodeLLDB\",\n      \"configuration\": {\n        \"pid\": \"${PID}\"\n      }\n    }\n  }\n}\n\n```\n\n\u003cimg width=\"1031\" alt=\"Screenshot 2022-10-09 at 11 27 13\" src=\"https://user-images.githubusercontent.com/10584846/194751648-72419216-2e4c-4ddc-adf7-9008f7e4f3c2.png\"\u003e\n\n## Python\n\n* Python: [debugpy][]\n* Install with `install_gadget.py --enable-python` or `:VimspectorInstall\n  debugpy`, ideally requires a working compiler and the python development\n  headers/libs to build a C python extension for performance.\n* ***NOTE***: Debugpy no longer supports python 2. In order to continue to debug\n  python 2 applications, use the `debugpy-python2` adapter after installing the\n  `debugpy-python2` gadget.\n\n* Full options: https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings\n\n```json\n{\n  \"configurations\": {\n    \"\u003cname\u003e: Launch\": {\n      \"adapter\": \"debugpy\",\n      \"filetypes\": [ \"python\" ],\n      \"configuration\": {\n        \"name\": \"\u003cname\u003e: Launch\",\n        \"type\": \"python\",\n        \"request\": \"launch\",\n        \"cwd\": \"\u003cworking directory\u003e\",\n        \"python\": \"/path/to/python/interpreter/to/use\",\n        \"stopOnEntry\": true,\n        \"console\": \"externalTerminal\",\n        \"debugOptions\": [],\n        \"program\": \"\u003cpath to main python file\u003e\"\n      }\n    }\n    ...\n  }\n}\n```\n\n### Python Remote Debugging\n\nIn order to use remote debugging with debugpy, you have to connect Vimspector\ndirectly to the application that is being debugged. This is easy, but it's a\nlittle different from how we normally configure things. Specifically, you need\nto:\n\n\n* Start your application with debugpy, specifying the `--listen` argument. See\n  [the debugpy\n  documentation](https://github.com/microsoft/debugpy#debugpy-cli-usage) for\n  details.\n* Use the built-in \"multi-session\" adapter. This just asks for the host/port to\n  connect to. For example:\n\n```json\n{\n  \"configurations\": {\n    \"Python Attach\": {\n      \"adapter\": \"multi-session\",\n      \"filetypes\": [ \"python\" ], // optional\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"pathMappings\": [\n          // mappings here (optional)\n        ]\n      }\n    }\n  }\n}\n```\n\nSee [details of the launch\nconfiguration](https://github.com/microsoft/debugpy/wiki/Debug-configuration-settings)\nfor explanation of things like `pathMappings`.\n\nAdditional documentation, including how to do this when the remote machine can\nonly be contacted via SSH [are provided by\ndebugpy](https://github.com/microsoft/debugpy/wiki/Debugging-over-SSH).\n\n### Python Remote launch and attach\n\nIf you're feeling fancy, checkout the [reference guide][remote-debugging] for\nan example of getting Vimspector to remotely launch and attach.\n\n### Python 2\n\nIn order to continue to debug python 2 applications, ensure that you install the\n`debugpy-python2` gadget (e.g. `--force-enable-python2` or\n`:VimspectorInstall debugpy-python2`), and then change your configuration to\nuse:\n\n```json\n{\n  \"configurations\": {\n    \"Python Attach\": {\n      \"adapter\": \"debugpy-python2\",\n      // ...\n    }\n  }\n}\n\n```\n\nfor example\n\n## TCL\n\n* TCL (TclProDebug)\n\nRequires TCL 8.x. Does not work with TCL 9.\n\nSee [my fork of TclProDebug](https://github.com/puremourning/TclProDebug) for instructions.\n\n## C♯\n\n* C# - dotnet core\n\nInstall with `install_gadget.py --force-enable-csharp` or `:VimspectorInstall\nnetcoredbg`\n\n```json\n{\n  \"configurations\": {\n    \"launch - netcoredbg\": {\n      \"adapter\": \"netcoredbg\",\n      \"filetypes\": [ \"cs\", \"fsharp\", \"vbnet\" ], // optional\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${workspaceRoot}/bin/Debug/netcoreapp2.2/csharp.dll\",\n        \"args\": [],\n        \"stopAtEntry\": true,\n        \"cwd\": \"${workspaceRoot}\",\n        \"env\": {}\n      }\n    }\n  }\n}\n```\n\n## Go\n\n* Go (delve dap)\n\nRequires:\n\n* `install_gadget.py --enable-go` or `:VimspectorInstall delve`\n* `go 1.16` or later (YMMV on earlier versions)\n\nThis uses the DAP support built in to the delve debugger\n\n```json\n{\n  \"configurations\": {\n    \"run\": {\n      \"adapter\": \"delve\",\n      \"filetypes\": [ \"go\" ], // optional\n      \"variables\": {\n        // example, to disable delve's go version check\n        // \"dlvFlags\": \"--check-go-version=false\"\n      },\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${fileDirname}\",\n        \"mode\": \"debug\"\n      }\n    }\n  }\n}\n```\n\nUse Variables to configure the following:\n\n* `dlvFlags`: (string) additional command line arguments to pass to delve\n\nThe debugger (delve) is launched in a terminal window so that you can see its\noutput and pass input to the debuggee.\n\nSee [vscode-go docs](https://github.com/golang/vscode-go/blob/master/docs/debugging.md#launchjson-attributes) for full launch options.\nYes, it seems that's the only place they are documented (apparently, they are\nnot documented by delve itself).\n\n\nThe vscode-go docs also have useful\n[troubleshooting information](https://github.com/golang/vscode-go/blob/master/docs/debugging.md#troubleshooting)\n\n* Go (legacy vscode-go)\n\nRequires:\n\n* `install_gadget.py --enable-go` or `:VimspectorInstall vscode-go`\n* [Delve][delve-install] installed, e.g. `go get -u github.com/go-delve/delve/cmd/dlv`\n* Delve to be in your PATH, or specify the `dlvToolPath` launch option\n\nNOTE: Vimspector uses the [\"legacy\" vscode-go debug adapter](https://github.com/golang/vscode-go/blob/master/docs/debugging-legacy.md) rather than the \"built-in\" DAP support in Delve. You can track https://github.com/puremourning/vimspector/issues/186 for that.\n\n```json\n{\n  \"configurations\": {\n    \"run\": {\n      \"adapter\": \"vscode-go\",\n      \"filetypes\": [ \"go\" ], // optional\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${fileDirname}\",\n        \"mode\": \"debug\",\n        \"dlvToolPath\": \"$HOME/go/bin/dlv\"\n        // example, to disable delve's go version check\n        // \"dlvFlags\": [ \"--check-go-version=false\" ]\n      }\n    }\n  }\n}\n```\n\nSee the vscode-go docs for\n[troubleshooting information](https://github.com/golang/vscode-go/blob/master/docs/debugging-legacy.md#troubleshooting)\n\n## PHP\n\nThis uses the php-debug, see\nhttps://marketplace.visualstudio.com/items?itemName=felixfbecker.php-debug\n\nRequires:\n\n* (optional) Xdebug helper for chrome https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc\n* `install_gadget.py --force-enable-php` or `:VimspectorInstall\n  vscode-php-debug`\n* configured php xdebug extension\n* nodejs for vscode-php-debug\n```ini\nzend_extension=xdebug.so\nxdebug.remote_enable=on\nxdebug.remote_handler=dbgp\nxdebug.remote_host=localhost\nxdebug.remote_port=9000\n```\nreplace `localhost` with the ip of your workstation.\n\nlazy alternative\n```ini\nzend_extension=xdebug.so\nxdebug.remote_enable=on\nxdebug.remote_handler=dbgp\nxdebug.remote_connect_back=true\nxdebug.remote_port=9000\n```\n\n* .vimspector.json\n```json\n{\n  \"configurations\": {\n    \"Listen for XDebug\": {\n      \"adapter\": \"vscode-php-debug\",\n      \"filetypes\": [ \"php\" ], // optional\n      \"configuration\": {\n        \"name\": \"Listen for XDebug\",\n        \"type\": \"php\",\n        \"request\": \"launch\",\n        \"port\": 9000,\n        \"stopOnEntry\": false,\n        \"pathMappings\": {\n          \"/var/www/html\": \"${workspaceRoot}\"\n        }\n      }\n    },\n    \"Launch currently open script\": {\n      \"adapter\": \"vscode-php-debug\",\n      \"filetypes\": [ \"php\" ], // optional\n      \"configuration\": {\n        \"name\": \"Launch currently open script\",\n        \"type\": \"php\",\n        \"request\": \"launch\",\n        \"program\": \"${file}\",\n        \"cwd\": \"${fileDirname}\",\n        \"port\": 9000\n      }\n    }\n  }\n}\n```\n\n### Debug web application\nappend `XDEBUG_SESSION_START=xdebug` to your query string\n```\ncurl \"http://localhost?XDEBUG_SESSION_START=xdebug\"\n```\nor use the previously mentioned Xdebug Helper extension (which sets a `XDEBUG_SESSION` cookie)\n\n### Debug cli application\n\n```sh\nexport XDEBUG_CONFIG=\"idekey=xdebug\"\nphp \u003cpath to script\u003e\n```\n\n## JavaScript and TypeScript\n\n* Node.js\n\nThis uses [vscode-js-debug](https://github.com/microsoft/vscode-js-debug), the\ndebugger that is used in vscode as well. For additional configurations, check\nthe documentation [here](https://github.com/microsoft/vscode-js-debug/blob/main/OPTIONS.md).\n\nTo install vscode-js-debug, run `VimspectorInstall vscode-js-debug` from vim or\nrun the install script `install_gadget.py --force-enable-node`. There are\nmultiple examples which you can check out. Find them under\n`support/test/node/simple`, `support/test/node/multiprocess` and\n`support/test/node/typescript`. A typical configuration for debugging typescript\nlooks like this:\n\n```json\n\n{\n  \"configurations\": {\n    \"run - js-debug\": {\n      \"adapter\": \"js-debug\",\n      \"filetypes\": [ \"javascript\", \"typescript\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"program\": \"${workspaceRoot}/src/index.ts\",\n        \"cwd\": \"${workspaceRoot}\",\n        \"stopOnEntry\": false,\n        \"type\": \"pwa-node\"\n      },\n      // 'breakpoints' is an optional part. This is a way to configure exception\n      // breakpoints. You can leave this out or set as you prefer.\n      \"breakpoints\": {\n        \"exception\": {\n          \"all\": \"N\",\n          \"uncaught\": \"N\"\n        }\n      }\n    }\n  }\n}\n\n```\n\n`vscode-js-debug` supports a number of different \"types\" and can do some stuff\nthat may or may not work. The `type` field is sadly not documented, but the\nvalid values are [defined here in the DebugType enum](https://github.com/microsoft/vscode-js-debug/blob/main/src/common/contributionUtils.ts#L61).\n\nVimspector has only been tested with `pwa-node` type.\n\nNote also that for some reason this debug adapter always forces us to start\nmultiple debug sessions. For a user, that shouldn't change anything (other than\nperhaps a slightly confusing stack trace). But it does make things more\ncomplicated and so there may be subtle bugs.\n\n* Chrome/Firefox\n\nThis uses the chrome/firefox debugger (they are very similar), see\nhttps://marketplace.visualstudio.com/items?itemName=msjsdiag.debugger-for-chrome and\nhttps://marketplace.visualstudio.com/items?itemName=firefox-devtools.vscode-firefox-debug, respectively.\n\nIt allows you to debug scripts running inside chrome from within Vim.\n\n* `./install_gadget.py --force-enable-chrome` or `:VimspectorInstall\n  debugger-for-chrome`\n* `./install_gadget.py --force-enable-firefox` or `:VimspectorInstall\n  debugger-for-firefox`\n* Example: `support/test/web`\n\n```json\n{\n  \"configurations\": {\n    \"chrome\": {\n      \"adapter\": \"chrome\",\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"url\": \"http://localhost:1234/\",\n        \"webRoot\": \"${workspaceRoot}/www\"\n      }\n    },\n    \"firefox\": {\n      \"adapter\": \"firefox\",\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"url\": \"http://localhost:1234/\",\n        \"webRoot\": \"${workspaceRoot}/www\",\n        \"reAttach\": true\n      }\n    }\n  }\n}\n```\n\n## Java\n\nVimspector works well with the [java debug server][java-debug-server], which\nruns as a jdt.ls (Java Language Server) plugin, rather than a standalone\ndebug adapter.\n\nVimspector is not in the business of running language servers, only debug\nadapters, so this means that you need a compatible Language Server Protocol\neditor plugin to use Java. I recommend [YouCompleteMe][], which has full support\nfor jdt.ls, and most importantly a trivial way to load the debug adapter and to\nuse it with Vimspector.\n\n### Hot code replace\n\nWhen using the [java debug server][java-debug-server], Vimspector supports the\nhot code replace custom feature. By default, when the underlying class files\nchange, vimspector asks the user if they wish to reload these classes at\nruntime.\n\nThis behaviour can be customised:\n\n* `let g:vimspector_java_hotcodereplace_mode = 'ask'` - the default, ask the\n  user for each reload.\n* `let g:vimspector_java_hotcodereplace_mode = 'always'` - don't ask, always\n  reload\n* `let g:vimspector_java_hotcodereplace_mode = 'never'` - don't ask, never\n  reload\n\n### Usage with YouCompleteMe\n\n* Set up [YCM for java][YcmJava].\n* Get Vimspector to download the java debug plugin:\n   `install_gadget.py --force-enable-java \u003cother options...\u003e` or\n   `:VimspectorInstall java-debug-adapter`\n* Configure Vimspector for your project using the `vscode-java` adapter, e.g.:\n\n```json\n{\n  \"configurations\": {\n    \"Java Attach\": {\n      \"adapter\": \"vscode-java\",\n      \"filetypes\": [ \"java\" ],\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"hostName\": \"${host}\",\n        \"port\": \"${port}\",\n        \"sourcePaths\": [\n          \"${workspaceRoot}/src/main/java\",\n          \"${workspaceRoot}/src/test/java\"\n        ]\n      }\n    }\n  }\n}\n```\n\n* Tell YCM to load the debugger plugin. This should be the `gadgets/\u003cos\u003e`\n  directory, not any specific adapter. e.g. in `.vimrc`\n\n```viml\n\" Tell YCM where to find the plugin. Add to any existing values.\nlet g:ycm_java_jdtls_extension_path = [\n  \\ '\u003c/path/to/Vimspector/gadgets/\u003cos\u003e'\n  \\ ]\n```\n\n* Create a mapping, such as `\u003cleader\u003e\u003cF5\u003e` to start the debug server and launch\n  vimspector, e.g. in `~/.vim/ftplugin/java.vim`:\n\n```viml\nlet s:jdt_ls_debugger_port = 0\nfunction! s:StartDebugging()\n  if s:jdt_ls_debugger_port \u003c= 0\n    \" Get the DAP port\n    let s:jdt_ls_debugger_port = youcompleteme#GetCommandResponse(\n      \\ 'ExecuteCommand',\n      \\ 'vscode.java.startDebugSession' )\n\n    if s:jdt_ls_debugger_port == ''\n       echom \"Unable to get DAP port - is JDT.LS initialized?\"\n       let s:jdt_ls_debugger_port = 0\n       return\n     endif\n  endif\n\n  \" Start debugging with the DAP port\n  call vimspector#LaunchWithSettings( { 'DAPPort': s:jdt_ls_debugger_port } )\nendfunction\n\nnnoremap \u003csilent\u003e \u003cbuffer\u003e \u003cLeader\u003e\u003cF5\u003e :call \u003cSID\u003eStartDebugging()\u003cCR\u003e\n\n```\n\nYou can then use `\u003cLeader\u003e\u003cF5\u003e` to start debugging rather than just `\u003cF5\u003e`.\n\nIf you see \"Unable to get DAP port - is JDT.LS initialized?\", try running\n`:YcmCompleter ExecuteCommand vscode.java.startDebugSession` and note the\noutput. If you see an error like `ResponseFailedException: Request failed:\n-32601: No delegateCommandHandler for vscode.java.startDebugSession`, make sure\nthat:\n* Your YCM jdt.ls is actually working, see the\n  [YCM docs](https://github.com/ycm-core/YouCompleteMe#troubleshooting) for\n  troubleshooting\n* The YCM jdt.ls has had time to initialize before you start the debugger\n* That `g:ycm_java_jdtls_extension_path` is set in `.vimrc` or prior to YCM\n  starting\n\nFor the launch arguments, see the\n[vscode document](https://code.visualstudio.com/docs/java/java-debugging).\n\n### Other LSP clients\n\nSee [this issue](https://github.com/puremourning/vimspector/issues/3) for more\nbackground.\n\n## Lua\n\nLua is supported through\n[local-lua-debugger-vscode](https://github.com/tomblind/local-lua-debugger-vscode).\nThis debugger uses stdio to communicate with the running process, so calls to\n`io.read` will cause problems.\n\n* `./install_gadget.py --enable-lua` or `:VimspectorInstall local-lua-debugger-vscode`\n* Examples: `support/test/lua/simple` and `support/test/lua/love`\n\n```json\n{\n  \"$schema\": \"https://puremourning.github.io/vimspector/schema/vimspector.schema.json#\",\n  \"configurations\": {\n    \"lua\": {\n      \"adapter\": \"lua-local\",\n      \"filetypes\": [ \"lua\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"type\": \"lua-local\",\n        \"cwd\": \"${workspaceFolder}\",\n        \"program\": {\n          \"lua\": \"lua\",\n          \"file\": \"${file}\"\n        }\n      }\n    },\n    \"luajit\": {\n      \"adapter\": \"lua-local\",\n      \"filetypes\": [ \"lua\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"type\": \"lua-local\",\n        \"cwd\": \"${workspaceFolder}\",\n        \"program\": {\n          \"lua\": \"luajit\",\n          \"file\": \"${file}\"\n        }\n      }\n    },\n    \"love\": {\n      \"adapter\": \"lua-local\",\n      \"filetypes\": [ \"love\" ],\n      \"configuration\": {\n        \"request\": \"launch\",\n        \"type\": \"lua-local\",\n        \"cwd\": \"${workspaceFolder}\",\n        \"program\": {\n          \"command\": \"love\"\n        },\n        \"args\": [\"${workspaceFolder}\"]\n      }\n    }\n  }\n}\n```\n\n## Other servers\n\n* Java - vscode-javac. This works, but is not as functional as Java Debug\n  Server. Take a look at [this\n  comment](https://github.com/puremourning/vimspector/issues/3#issuecomment-576916076)\n  for instructions.\n- See also [the wiki](https://github.com/puremourning/vimspector/wiki/Additional-Language-Support)\n  which has community-contributed plugin files for some languages.\n\n\n# Customisation\n\nThere is very limited support for customisation of the UI.\n\n## Changing the default signs\n\nVimspector uses the following signs internally. If they are defined before\nVimspector uses them, they will not be replaced. So to customise the signs,\ndefine them in your `vimrc`.\n\n\n| Sign                      | Description                             | Priority |\n|---------------------------|-----------------------------------------|----------|\n| `vimspectorBP`            | Line breakpoint                         | 9        |\n| `vimspectorBPCond`        | Conditional line breakpoint             | 9        |\n| `vimspectorBPLog`         | Logpoint                                | 9        |\n| `vimspectorBPDisabled`    | Disabled breakpoint                     | 9        |\n| `vimspectorPC`            | Program counter (i.e. current line)     | 200      |\n| `vimspectorPCBP`          | Program counter and breakpoint          | 200      |\n| `vimspectorNonActivePC`   | Program counter for non-focused thread  | 9        |\n| `vimspectorCurrentThread` | Focussed thread in stack trace view     | 200      |\n| `vimspectorCurrentFrame`  | Current stack frame in stack trace view | 200      |\n\nThe default symbols are the equivalent of something like the following:\n\n```viml\nsign define vimspectorBP            text=\\ ● texthl=WarningMsg\nsign define vimspectorBPCond        text=\\ ◆ texthl=WarningMsg\nsign define vimspectorBPLog         text=\\ ◆ texthl=SpellRare\nsign define vimspectorBPDisabled    text=\\ ● texthl=LineNr\nsign define vimspectorPC            text=\\ ▶ texthl=MatchParen linehl=CursorLine\nsign define vimspectorPCBP          text=●▶  texthl=MatchParen linehl=CursorLine\nsign define vimspectorNonActivePC   linehl=DiffAdd\nsign define vimspectorCurrentThread text=▶   texthl=MatchParen linehl=CursorLine\nsign define vimspectorCurrentFrame  text=▶   texthl=Special    linehl=CursorLine\n```\n\nIf the signs don't display properly, your font probably doesn't contain these\nglyphs. You can easily change them by defining the sign in your vimrc. For\nexample, you could put this in your `vimrc` to use some simple ASCII symbols:\n\n```viml\nsign define vimspectorBP text=o             texthl=WarningMsg\nsign define vimspectorBPCond text=o?        texthl=WarningMsg\nsign define vimspectorBPLog text=!!         texthl=SpellRare\nsign define vimspectorBPDisabled text=o!    texthl=LineNr\nsign define vimspectorPC text=\\ \u003e           texthl=MatchParen\nsign define vimspectorPCBP text=o\u003e          texthl=MatchParen\nsign define vimspectorCurrentThread text=\u003e  texthl=MatchParen\nsign define vimspectorCurrentFrame text=\u003e   texthl=Special\n```\n\n## Sign priority\n\nMany different plugins provide signs for various purposes. Examples include\ndiagnostic signs for code errors, etc. Vim provides only a single priority to\ndetermine which sign should be displayed when multiple signs are placed at a\nsingle line. If you are finding that other signs are interfering with\nvimspector's (or vice-versa), you can customise the priority used by vimspector\nby setting the following dictionary:\n\n```viml\nlet g:vimspector_sign_priority = {\n  \\   '\u003csign-name\u003e': \u003cpriority\u003e,\n  \\ }\n```\n\nFor example:\n\n```viml\nlet g:vimspector_sign_priority = {\n  \\    'vimspectorBP':          3,\n  \\    'vimspectorBPCond':      3,\n  \\    'vimspectorBPLog':       3,\n  \\    'vimspectorBPDisabled':  3,\n  \\    'vimspectorNonActivePC': 3,\n  \\    'vimspectorPC':          999,\n  \\    'vimspectorPCBP':        999,\n  \\ }\n```\n\nAll keys are optional. If a sign is not customised, the default priority it used\n(as shown above).\n\nSee `:help sign-priority`. The default priority is 10, larger numbers override\nsmaller ones.\n\n***NOTE***: The default `vimspectorNonActivePC` sign does not add any text to\nthe sign column, it simply adds a line highlight so that you can see the lines\nwhere other threads or processes are currently stopped. As a result this sign\nnormally should _merge_ with any sign that adds a symbol (such as a breakpoint\nsign).  Vim will only merge the properties of signs with the same priority, so\nif changing the default priorities, it's recommended that:\n\n1. All the breakpoint signs (`vimspectorBP`, `vimspectorBPCond`, etc.) have the\n   same priority.\n2. You also set the `vimspectorNonActivePC` sign that same priority\n3. Active PC ( `vimspectorPC`, `vimspectorPCBP`, etc.) have a higher priority.\n\n## Presentation Hints\n\n***NOTE:*** This customisation point is currently ***unusable*** and may change\nat any time.\n\nSometimes the Debug Adapter provides hints as to how the UI should display\ncertain things. This includes stack frames, variables etc.\n\nVimspector provides a simple way to customise how these are displayed, by\nsetting values in the dictionary `g:vimspector_presentation_hint_hl`.\n\nThe following keys are supported with the mentioned default highlight group.\n\n\n| Group        | Key           | Usage                                                           | Default      |\n| ------------ | ------------  | -------------------------------------                           | ------------ |\n| *all*        | `normal`      | anything not covered below                                      | `Normal`     |\n| Stack trace  | `emphasize`   | emphasize sources in stack trace                                | `Title`      |\n| Stack trace  | `deemphasize` | deemphasize sources in stack trace                              | `Conceal`    |\n| Stack trace  | `label`       | stack frames which are \"labels\", not representing actual frames | `NonText`    |\n| Stack trace  | `subtle`      | stack frames which are internal or not interesting              | `Conceal`    |\n| Scopes       | `arguments`   | Function arguments scope                                        | `Title`      |\n| Scopes       | `locals`      | Local variables scope                                           | `Title`      |\n| Scopes       | `registers`   | Registers scope                                                 | `Title`      |\n| Variables    | `property`    | Function arguments scope                                        | `Identifier` |\n| Variables    | `method`      | Local variables scope                                           | `Function`   |\n| Variables    | `class`       | Registers scope                                                 | `Type`       |\n| Variables    | `data`        | Registers scope                                                 | `String`     |\n\nIn addition, any value supplied in the DAP `VariablePresentationHint` can be set\nwhich will be used if supplied by the debug adapter.\n\nA silly example; the defaults should probably be OK for most colour schemes:\n\n```viml\nlet g:vimspector_presentation_hint_hl = {\n  \\    'normal': 'Identifier',\n  \\    'label':  'Title',\n  \\ }\n```\n\n\n## Changing the default window sizes\n\n\u003e ***Please Note***: This customisation API is ***unstable***, meaning that it may\nchange at any time. I will endeavour to reduce the impact of this and announce\nchanges in Gitter.\n\nThe following options control the default sizes of the UI windows (all of them\nare numbers)\n\n- `g:vimspector_sidebar_width` (default: 50 columns):\n   The width in columns of the left utility windows (variables, watches, stack\n   trace)\n- `g:vimspector_bottombar_height` (default 10 lines):\n   The height in rows of the output window below the code window.\n\nExample:\n\n```viml\nlet g:vimspector_sidebar_width = 75\nlet g:vimspector_bottombar_height = 15\n```\n\n## Changing the terminal size\n\nThe terminal is typically created as a vertical split to the right of the code\nwindow, and that window is re-used for subsequent terminal buffers.\nThe following control the sizing of the terminal window used\nfor debuggee input/output when using Vim's built-in terminal.\n\n- `g:vimspector_code_minwidth` (default: 82 columns):\n  Minimum number of columns to try and maintain for the code window when\n  splitting to create the terminal window.\n- `g:vimspector_terminal_maxwidth` (default: 80 columns):\n  Maximum number of columns to use for the terminal.\n- `g:vimspector_terminal_minwidth` (default: 10 columns):\n  Minimum number of columns to use when it is not possible to fit\n  `g:vimspector_terminal_maxwidth` columns for the terminal.\n\nThat's a lot of options, but essentially we try to make sure that there are at\nleast `g:vimspector_code_minwidth` columns for the main code window and that the\nterminal is no wider than `g:vimspector_terminal_maxwidth` columns.\n`g:vimspector_terminal_minwidth` is there to ensure that there's a reasonable\nnumber of columns for the terminal even when there isn't enough horizontal space\nto satisfy the other constraints.\n\nExample:\n\n```viml\nlet g:vimspector_code_minwidth = 90\nlet g:vimspector_terminal_maxwidth = 75\nlet g:vimspector_terminal_minwidth = 20\n```\n\n## Custom mappings while debugging\n\nIt's useful to be able to define mappings only while debugging and remove those\nmappings when debugging is complete. For this purpose, Vimspector provides 2\n`User` autocommands:\n\n* `VimspectorJumpedToFrame` - triggered whenever a 'break' event happens, or\n  when selecting a stack from to jump to. This can be used to create (for\n  example) buffer-local mappings for any files opened in the code window.\n* `VimspectorDebugEnded` - triggered when the debug session is terminated\n  (actually when Vimspector is fully reset)\n\nAn example way to use this is included in `support/custom_ui_vimrc`. In there,\nthese autocommands are used to create buffer-local mappings for any files\nvisited while debugging and to clear them when completing debugging. This is\nparticularly useful for commands like `\u003cPlug\u003eVimspectorBalloonEval` which only\nmake sense while debugging (and only in the code window). Check the commented\nsection `Custom mappings while debugging`.\n\nNOTE: This is a fairly advanced feature requiring some nontrivial vimscript.\nIt's possible that this feature will be incorporated into Vimspector in future\nas it is a common requirement.\n\n\n## Pre-launch building strategies\n\nIn many cases you will want to rebuild your project before starting a new debugging\nsession. Vimspector is not a task manager and implementing this functionality\nis out of the scope of this project. However, there are some strategies described in the\n[community wiki](https://github.com/puremourning/vimspector/wiki/Pre-launch-building-strategies)\nto achieve similar functionality.\n\n\n## Disabling the WinBar\n\nYou can tell vimspector not to draw the WinBar (the toolbars in the code,\nvariables, output, etc. windows) by setting:\n\n```viml\nlet g:vimspector_enable_winbar=0\n```\n\nThe WinBar is in any case not displayed if the mouse is not enabled.\n\n## Advanced UI customisation\n\n\u003e ***Please Note***: This customisation API is ***unstable***, meaning that it may\nchange at any time. I will endeavour to reduce the impact of this and announce\nchanges in Gitter.\n\nThe above customisation of window sizes is limited intentionally to keep things\nsimple. Vimspector also provides a way for you to customise the UI without\nrestrictions, by running a `User` autocommand just after creating the UI or\nopening the terminal. This requires you to write some vimscript, but allows you\nto do things like:\n\n* Hide a particular window or windows\n* Move a particular window or windows\n* Resize windows\n* Have multiple windows for a particular buffer (say, you want 2 watch windows)\n* etc.\n\nYou can essentially do anything you could do manually by writing a little\nvimscript code.\n\nThe `User` autocommand is raised with `pattern` set with the following values:\n\n* `VimspectorUICreated`: Just after setting up the UI for a debug session\n* `VimspectorTerminalOpened`: Just after opening the terminal window for program\n  input/output.\n\nThe following global variable is set up for you to get access to the UI\nelements: `g:vimspector_session_windows`. This is a `dict` with the following\nkeys:\n\n* `g:vimspector_session_windows.tabpage`: The tab page for the session\n* `g:vimspector_session_windows.variables`: Window ID of the variables window,\n  containing the `vimspector.Variables` buffer.\n* `g:vimspector_session_windows.watches`: Window ID of the watches window,\n  containing the `vimspector.Watches` buffer.\n* `g:vimspector_session_windows.stack_trace`: Window ID of the stack trade\n  window containing the `vimspector.StackTrace` buffer.\n* `g:vimspector_session_windows.code`: Window ID of the code window.\n* `g:vimspector_session_windows.output`: Window ID of the output window.\n\nIn addition, the following key is added when triggering the\n`VimspectorTerminalOpened` event:\n\n* `g:vimspector_session_windows.terminal`: Window ID of the terminal window\n\n## Customising the WinBar\n\nYou can even customise the WinBar buttons by simply running the usual `menu`\n(and `unmenu`) commands.\n\nBy default, Vimspector uses something a bit like this:\n\n```viml\nnnoremenu WinBar.■\\ Stop :call vimspector#Stop( { 'interactive': v:false } )\u003cCR\u003e\nnnoremenu WinBar.▶\\ Cont :call vimspector#Continue()\u003cCR\u003e\nnnoremenu WinBar.▷\\ Pause :call vimspector#Pause()\u003cCR\u003e\nnnoremenu WinBar.↷\\ Next :call vimspector#StepOver()\u003cCR\u003e\nnnoremenu WinBar.→\\ Step :call vimspector#StepInto()\u003cCR\u003e\nnnoremenu WinBar.←\\ Out :call vimspector#StepOut()\u003cCR\u003e\nnnoremenu WinBar.⟲: :call vimspector#Restart()\u003cCR\u003e\nnnoremenu WinBar.✕ :call vimspector#Reset( { 'interactive': v:false } )\u003cCR\u003e\n```\n\nIf you prefer a different layout or if the unicode symbols don't render\ncorrectly in your font, you can customise this in the `VimspectorUICreated`\nautocommand, for example:\n\n```viml\nfunc! CustomiseUI()\n  call win_gotoid( g:vimspector_session_windows.code )\n  \" Clear the existing WinBar created by Vimspector\n  nunmenu WinBar\n  \" Create our own WinBar\n  nnoremenu WinBar.Kill :call vimspector#Stop( { 'interactive': v:true } )\u003cCR\u003e\n  nnoremenu WinBar.Continue :call vimspector#Continue()\u003cCR\u003e\n  nnoremenu WinBar.Pause :call vimspector#Pause()\u003cCR\u003e\n  nnoremenu WinBar.Step\\ Over  :call vimspector#StepOver()\u003cCR\u003e\n  nnoremenu WinBar.Step\\ In :call vimspector#StepInto()\u003cCR\u003e\n  nnoremenu WinBar.Step\\ Out :call vimspector#StepOut()\u003cCR\u003e\n  nnoremenu WinBar.Restart :call vimspector#Restart()\u003cCR\u003e\n  nnoremenu WinBar.Exit :call vimspector#Reset()\u003cCR\u003e\nendfunction\n\naugroup MyVimspectorUICustomistaion\n  autocmd!\n  autocmd User VimspectorUICreated call s:CustomiseUI()\naugroup END\n```\n\n## Example\n\nThere is some example code in `support/custom_ui_vimrc` showing how you can use\nthe window IDs to modify various aspects of the UI using some basic vim\ncommands, primarily `win_gotoid` function and the `wincmd` ex command.\n\nTo try this out `vim -Nu support/custom_ui_vimrc \u003csome file\u003e`.\n\nHere's a rather smaller example. A simple way to use this is to drop it into a\nfile named `my_vimspector_ui.vim` in `~/.vim/plugin` (or paste into your\n`vimrc`):\n\n```viml\n\" Set the basic sizes\nlet g:vimspector_sidebar_width = 80\nlet g:vimspector_code_minwidth = 85\nlet g:vimspector_terminal_minwidth = 75\n\nfunction! s:CustomiseUI()\n  \" Customise the basic UI...\n\n  \" Close the output window\n  call win_gotoid( g:vimspector_session_windows.output )\n  q\nendfunction\n\nfunction s:SetUpTerminal()\n  \" Customise the terminal window size/position\n  \" For some reasons terminal buffers in Neovim have line numbers\n  call win_gotoid( g:vimspector_session_windows.terminal )\n  set norelativenumber nonumber\nendfunction\n\naugroup MyVimspectorUICustomisation\n  autocmd!\n  autocmd User VimspectorUICreated call s:CustomiseUI()\n  autocmd User VimspectorTerminalOpened call s:SetUpTerminal()\naugroup END\n```\n\n# FAQ\n\n1. Q: Does it work with _this_ language? A: Probably, but it won't\n   necessarily be easy to work out what to put in the `.vimspector.json`. As you\n   can see above, some of the servers aren't really editor agnostic, and require\n   very-specific unique handling. See [the wiki](https://github.com/puremourning/vimspector/wiki/Additional-Language-Support) for details on additional language support\n3. How do I stop it starting a new Terminal.app on macOS? See [this\n   comment](https://github.com/puremourning/vimspector/issues/90#issuecomment-577857322)\n4. Can I specify answers to the annoying questions about exception breakpoints\n   in my `.vimspector.json` ? Yes, see [here][vimspector-ref-exception].\n5. Do I have to specify the file to execute in `.vimspector.json`, or could it be the current vim file?\n   You don't need to. You can specify $file for the current active file. See [here][vimspector-ref-var] for complete list of replacements in the configuration file.\n6. You allow comments in `.vimspector.json`, but Vim highlights these as errors,\n   do you know how to make this not-an-error? Yes, put this in\n   `~/.vim/after/syntax/json.vim`:\n\n```viml\nsyn region jsonComment start=\"/\\*\" end=\"\\*/\"\nhi link jsonCommentError Comment\nhi link jsonComment Comment\n```\n\n7. What is the difference between a `gadget` and an `adapter`? A gadget is\n   something you install with `:VimspectorInstall` or `install_gadget.py`, an\n   `adapter` is something that Vimspector talks to (actually it's the Vimspector\n   config describing that thing). These are _usually_ one-to-one,\n   but in theory a single gadget can supply multiple `adapter` configs.\n   Typically this happens when a `gadget` supplies different `adapter` config\n   for, say remote debugging, or debugging in a container, etc.\n8. The signs and winbar display funny symbols. How do I fix them? See\n   [this](#changing-the-default-signs) and [this](#customising-the-winbar)\n9. What's this telemetry stuff all about? Are you sending my data to evil companies?\n   Debug adapters (for some reason) send telemetry data to clients. Vimspector simply\n   displays this information in the output window. It *does not* and *will not ever*\n   collect, use, forward or otherwise share any data with any third parties.\n10. Do I _have_ to put a `.vimspector.json` in the root of every project? No, you\n    can use `g:vimspector_adapters` and `g:vimspector_configurations` or put all\n    of your adapter and debug configs in a [single directory](https://puremourning.github.io/vimspector/configuration.html#debug-configurations)\n    if you want to, but note the caveat that `${workspaceRoot}` won't be\n    calculated correctly in that case.  The vimsepctor author uses this [a lot](https://github.com/puremourning/.vim-mac/tree/master/vimspector-conf)\n11. I'm confused about remote debugging configuration, can you explain it?\n    eh... kind of. Reference:\n    https://puremourning.github.io/vimspector/configuration.html#remote-debugging-support.\n    Some explanations here too:\n    https://github.com/puremourning/vimspector/issues/478#issuecomment-943515093\n12. I'm trying to debug a Django (django?) project and it's not working. Can you\n    help? sure, check [this link which has a working example](https://www.reddit.com/r/neovim/comments/mz4ari/how_to_set_up_vimspector_for_django_debugging/).\n    Or google it.\n13. Can vimspector build my code before debugging it? Can I deploy it to a remote host before debugging it?\n    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](https://github.com/puremourning/vimspector/issues/227)\n14. 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).\n\n```json\n    \"Attach: max PID\": {\n      \"adapter\": \"CodeLLDB\",\n      \"variables\": {\n        \"pid\": {\n          \"shell\": [\n            \"/bin/bash\",\n            \"-c\",\n            \"pgrep vim | sort | tail -1\"\n          ]\n        }\n      },\n      \"configuration\": {\n        \"request\": \"attach\",\n        \"program\": \"${workspaceRoot}/src/vim\",\n        \"expressions\": \"native\",\n        \"stopOnEntry#json\": \"${StopOnEntry:true}\",\n        \"pid\": \"${pid}\"\n      }\n    },\n```\n\n\nExample `g:vimspector_adapters` and `g:vimspector_configurations`:\n\n```viml\nlet g:vimspector_adapters = #{\n      \\   test_debugpy: #{ extends: 'debugpy' }\n      \\ }\n\nlet g:vimspector_configurations = {\n      \\ \"test_debugpy_config\": {\n      \\   \"adapter\": \"test_debugpy\",\n      \\   \"filetypes\": [ \"python\" ],\n      \\   \"configuration\": {\n      \\     \"request\": \"launch\",\n      \\     \"type\": \"python\",\n      \\     \"cwd\": \"${fileDirname}\",\n      \\     \"args\": [],\n      \\     \"program\": \"${file}\",\n      \\     \"stopOnEntry\": v:false,\n      \\     \"console\": \"integratedTerminal\",\n      \\     \"integer\": 123,\n      \\   },\n      \\   \"breakpoints\": {\n      \\     \"exception\": {\n      \\       \"raised\": \"N\",\n      \\       \"uncaught\": \"\",\n      \\       \"userUnhandled\": \"\"\n      \\     }\n      \\   }\n      \\ } }\n```\n\n[ycmd]: https://github.com/Valloric/ycmd\n[gitter]: https://gitter.im/vimspector/Lobby?utm_source=share-link\u0026utm_medium=link\u0026utm_campaign=share-link\n[java-debug-server]: https://github.com/Microsoft/java-debug\n[website]: https://puremourning.github.io/vimspector-web/\n[delve]: https://github.com/go-delve/delve\n[delve-install]: https://github.com/go-delve/delve/tree/master/Documentation/installation\n[vimspector-ref]: https://puremourning.github.io/vimspector/configuration.html\n[vimspector-ref-var]: https://puremourning.github.io/vimspector/configuration.html#replacements-and-variables\n[vimspector-ref-exception]: https://puremourning.github.io/vimspector/configuration.html#exception-breakpoints\n[vimspector-ref-config-selection]: https://puremourning.github.io/vimspector/configuration.html#configuration-selection\n[debugpy]: https://github.com/microsoft/debugpy\n[YouCompleteMe]: https://github.com/ycm-core/YouCompleteMe#java-semantic-completion\n[remote-debugging]: https://puremourning.github.io/vimspector/configuration.html#remote-debugging-support\n[YcmJava]: https://github.com/ycm-core/YouCompleteMe#java-semantic-completion\n","funding_links":[],"categories":["Vim Script"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpuremourning%2Fvimspector","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fpuremourning%2Fvimspector","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fpuremourning%2Fvimspector/lists"}