With this change `startDebugging` should work out of the box for debug
adapters configured with type=server and an executable.
For example, for vscode-js-debug, instead of a custom adapter factory
like:
```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
```
It will be possible to use the simpler definition:
```lua
require("dap").adapters["pwa-node"] = {
type = "server",
host = "localhost",
port = "${port}",
executable = {
command = "node",
args = {"/path/to/js-debug/src/dapDebugServer.js", "${port}"},
}
}
```
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
```
Some debug adapters allow to resume execution using custom evaluate
commands. This unfortunately by-passes some logic that puts the client
into "running" state again.
If the client then receives a stopped event it assumed it
was already stopped and sent a continue request (unless
`auto_continue_if_many_stopped` was disabled)
This changes the condition to also jump if `stopped_thread_id ==
stopped.threadId`
Closes https://github.com/mfussenegger/nvim-dap/issues/898
Co-authored-by: xac <jiangfengxi.c@gmail.com>
When dap.ui.Layer.render is called with start == nil and end_ == nil, assign
start = 0 only when the buffer contains a single, empty line. For all other
cases, assign start == line-count instead of start == line-count - 1, which
appears to be causing the line swapping issue.
Add a simple test case where the buffer already contains non-empty lines, and a
new line is added with start == nil and end_ == nil, which should now be
appended to the end.
Otherwise the session remains in memory longer than necessary and the
sessions widget continues showing the child session until the parent
session ends.
E5108: Error executing lua:
~/.local/share/nvim/lazy/nvim-dap/lua/dap/breakpoints.lua:187: invalid
value (boolean) at index 2 in table for 'concat'
stack traceback:
[C]: in function 'concat'
~/.local/share/nvim/lazy/nvim-dap/lua/dap/breakpoints.lua:187: in function 'to_qf_list'
~/.local/share/nvim/lazy/nvim-dap/lua/dap.lua:723: in function 'list_breakpoints'
...azy/telescope-dap.nvim/lua/telescope/_extensions/dap.lua:115: in function 'list_breakpoints'
~/.config/nvim/lua/plugins/dap/init.lua:76: in function <~/.config/nvim/lua/plugins/dap/init.lua:75>
nvim-dap is a common dependency across Neovim plugins.
Using luarocks may alleviate the need for users to specify their
plugins' dependencies in their plugin manager
(e.g., vim-plug or packer). See also
[this blog post](https://teto.github.io/posts/2021-09-17-neovim-plugin-luarocks.html)
for details.
This PR adds a release workflow that publishes this plugin to
[LuaRocks](https://luarocks.org/) whenever a tag is pushed,
as well as a rockspec that can be used to release to the `dev` channel.
For the release workflow to work, someone with a LuaRocks account
will have to add their API key to this repo's secrets.
Note that I have added a shield to the readme that assumes the
existence of an `mfussenegger/nvim-dap` LuaRocks module.
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)
Not sure which debug adapters make use of this.
Basic implementation that shows title and message in the `status()`
function.
This will also allow extensions to subscribe to the events and display
the information in more sophisticated ways.
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.
