New breakpoint API/UI

[mfussenegger]

Problem Statement

• No good way to query for specific breakpoints via an API (Extend get api of breakpoints to retrieve a bp at specific line #1204)
• No good way to edit conditions or log statements of existing breakpoints (also Extend get api of breakpoints to retrieve a bp at specific line #1204)
• Deleting specific breakpoint requires either going through quickfix list or manually find each breakpoint and toggle them (Add UI and API for ease of control over breakpoints #448)
• Can't jump to next/prev breakpoint easily (Jump to next/previous breakpoint #792)

Possible Solutions

Nothing set in stone, but rough plan:

• New API:

  • dap.bp.get(opts) with filters
  • dap.bp.set(opts)
    • TDB: should cover data breakpoints and method breakpoints if possible
    • Should allow setting lnum, col, bufnr
  • dap.bp.jump([count])

• New dap-breakpoints:// virtual buffer

  • Lists all breakpoints including their conditions
  • Supports inline edits
  • :w to save changes (updating conditions, deleting them)

• Extend :DapBreakpoint user commands to either:

  • Edit existing condition/logpoints
  • Toggle

Considered Alternatives

No response

[przepompownia]

Two additional thoughts at the moment to consider:

• inactive breakpoints - removed for the adapter, still kept on the nvim-dap side, possible to reactivate later (I hope I didn't miss something existing),

• dap.bp.jump([step]) - could cycle modulo the count of (active) breakpoints.

[mfussenegger]

inactive breakpoints - removed for the adapter, still kept on the nvim-dap side, possible to reactivate later (I hope I didn't miss something existing),

I'm not too keen on this because of its UI implications. Going from present/absent to present/inactive/absent requires additional toggle options. I have so far never wanted it or missed it given how easy it is to re-add one, but I'll keep it in mind

[przepompownia]

Adding it back is easy, as long as I remember where it was…

It's easy for me to forget it as I delve into a stack of rarely visited places, searching for a target breakpoint, but leaving a few intermediate breakpoints behind (for use if the deepest one turned out to be positioned incorrectly). Most of these intermediate breakpoints could be inactive for me in such case.

[asmodeus812]

@mfussenegger one more point of interest is the setup of dap itself, as of now, since the listeners, and sevral other internal properties, have metatables attached to them we can not simply deep extend it, it would be nice if dap provided .setup function as most other plugins do otherwise at the moment i am doing something like that, as a workaround, which is quite bad.

    dap.adapters = vim.tbl_deep_extend("force",
        dap.adapters, dap_config.adapters or {})
    dap.configurations = vim.tbl_deep_extend("force",
        dap.configurations, dap_config.configurations or {})


    for k, v in pairs(dap_config.defaults.fallback or {}) do
        dap.defaults.fallback[k] = v
    end
    for k, v in pairs(dap_config.listeners or {}) do
        for l, c in pairs(v) do
            for m, f in pairs(c) do
                dap.listeners[k][l][m] = f
            end
        end
    end

[mfussenegger]

it would be nice if dap provided .setup function as most other plugins do otherwise at the moment i am doing something like that, as a workaround, which is quite bad.

I don't see how this is related to the breakpoints API and I'm not going to add one because adapters, configurations and listeners can be changed at any time from multiple plugins.

Why do you go through a dap_config table instead of doing the assignments directly?

[asmodeus812]

I posted it as comment here, did not want to make a separate issue, but if a new issue for this is required will do.

However while the current behavior should remain, being able to dynamically set listeners the way we do, which i never implied should be removed, what i was pointing is that there is no easy .setup api to initialize the plugin in a declarative way, with user defaults, there are certain config options which are only set initially and pretty much never modified (usually) e.g defaults.fallback. table and so on. While other plugins might modify them like dap-ui, that is true, but as said above, the current behavior of setting them via the require("dap") table is okay, i would like to use have/use the more widely spread declarative way to setup plugins as well for setting up the initial state of dap. Here is the dap_config table i iterate over in the snippet from above.

{
        defaults = {
            fallback = {
                focus_terminal = false,
                exception_breakpoints = "default",
                terminal_win_cmd = make_terminal_view,
            },
        },
        listeners = {
            after = {
                disconnect = {
                    dap_user = function(args)
                        dapui.close_debug_view()
                        debugger_terminate_session(args)
                    end,
                },
                event_terminated = {
                    dap_user = function(args)
                        dapui.close_debug_view()
                        debugger_terminate_session(args)
                        open_terminal_view(args.config.name, false)
                    end,
                },
                event_initialized = {
                    dap_user = function(args)
                        dapui.open_debug_view(1)
                        dapui.open_debug_view(2)
                        debugger_initiate_session(args)
                        open_terminal_view(args.config.name, true)
                    end,
                },
                event_stopped = {
                    dap_user = function(args)
                        debugger_focus_session(args)
                    end,
                },
            },
        },
    }

[sleeptightAnsiC]

There are some feature requests in nvim-dap-ui that partially would benefit from those API changes:

• feature: interface for adding breakpoint conditions rcarriga/nvim-dap-ui#414 - I've mentioned how adding new breakpoints is problematic because dap.toggle_breakpoint() always sets it on a current line in the buffer.
• Question: is it possible to monitor stack/variables on the go? rcarriga/nvim-dap-ui#338 - Not sure if I understand this one right. It asks for better Logpoints/Watchpoints that would just pretty much dump the context of whole frame. Not sure, if we can even support it at the moment (Logpoints are BPs under-the-hood).
• Break on application crash rcarriga/nvim-dap-ui#356 - (it's not an actual nvim-dap-ui issue) I've seen this problem mentioned in multiple places that some debuggers break on exceptions while others don't. Not sure if this is related to those API changes though as this is behavior of DAP's setExceptionBreakpoints

cc @mfussenegger