- Introduces a dap.providers.configs table which plugins can extend to
add additional sources for dynamic configuration generation
- Implements the two built-in configuration sources as providers
- `.vscode/launch.json` files are now loaded automatically by one of
these providers. The entries from the file always display even if the
type doesn't match the current filetype. This gets rid of the
`type_to_filetypes` mapping requirements.
This implements a file picker, to pick the file you want to execute with
the debugger.
Fixes#1130
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
For mappings like:
dap.repl.open()
dap.repl.execute(vim.fn.expand("<cexpr>"))
`widgets.hover()` is nice to zoom in on a single variable, but sometimes
you want to compare the values of several variables. Having their output
displayed in the REPL next to each other makes that easier.
For the `startDebugging` implementation of `vscode-js-debug` the client
needs to connect to the parent adapter instance.
This change enables an adapter configuration like this:
```lua
require("dap").adapters["pwa-node"] = function(on_config, config, parent)
local target = config["__pendingTargetId"]
if target and parent then
local adapter = parent.adapter --[[@as ServerAdapter]]
on_config({
type = "server",
host = "localhost",
port = adapter.port
})
else
on_config({
type = "server",
host = "localhost",
port = "${port}",
executable = {
command = "node",
args = {"/path/to/js-debug/src/dapDebugServer.js", "${port}"},
}
})
end
end
```
New API:
- `dap.sessions()` to return active debug sessions
- `dap.ui.widgets.sessions` to show active debug sessions
Step functions will change the focus automatically if the currently
focused session is not stopped.
This should make common scenarios like debugging client + server where
you step from making requests on the client to receiving request on the
server convenient.
Note that this is unrelated to `startDebugging` support. The PR here is
about concurrent top-level sessions. `startDebugging` support will
introduce hierarchical sessions. (Probably including something like
`children` in the `Session` object)
Moves lower level functions that users typically do not want to use
further down. E.g there is almost no reason to use `disconnect` or
`close`, but users should use `terminate()` instead.
Same for `launch` and `attach` which are low level APIs that users
should not call. There is `run` and `continue` instead.
Allows users to distinguish between their own requests and other
requests when listening.
The motiviation for this is that nvim-dap maintains some state
internally for its functionality (e.g. session.current_frame) which
nvim-dap-ui needs to be aware of so users don't have issues with the two
plugins showing different information. Some of this state is set after
requests such as `stackTrace` for the current frame. nvim-dap-ui needs
to listen for this and refresh after it has been processed. Issues arise
when the listener causes more stack trace requests, leading to infinite
recursive calls because the listener can't distinguish between calls
made by nvim-dap and itself.
This is occurring now because of a large refactor of nvim-dap-ui which
moves away from maintaining state (which previously used the nvim-dap
request result) to making direct calls to the debugging adapter for all
data.
if a sign is already set in some user config we do not overwrite the
value and skip it. This enables sign configuration by the user
regardless where the user requires the dap plugin
