Keep sub-entries expanded when stepping through code

[igorlfs]

Stepping collapses sub-entries, eg

becomes

[rcarriga]

I'm not seeing the same behaviour. Can you supply a reproduction (including nvim-dap config/adapter settings)?

[igorlfs]

I'm not seeing the same behaviour.

Whoops, should have been more clear with a reproduction 😅

Can you supply a reproduction (including nvim-dap config/adapter settings)?

I've tested with 2 adapters. The original one was lldb-vscode, with the following:

adapter settings

dap.adapters.lldb = {
    type = "executable",
    command = "/usr/bin/lldb-vscode",
    name = "lldb",
}

and

config

dap.configurations.cpp = {
    {
        name = "Launch",
        type = "lldb",
        request = "launch",
        program = vim.fn.getcwd() .. "/binary",
        cwd = vim.fn.getcwd(),
        stopOnEntry = false,
    },
}

Additionally, I also decided to test with debugpy:

(adapter settings)

dap.adapters.python = {
    type = "executable";
    command = "/usr/bin/python3";
    args = { "-m", "debugpy.adapter" };
}

(config)

dap.configurations.python = {
    {
        type = "python";
        request = "launch";
        name = "Launch file";

        program = "${file}";
        pythonPath = "/usr/bin/python"
    },
}

With debugpy, I observed a different behavior: while sub-entries don't get collapsed when stepping, they also don't get updated, needing to be manually closed and opened to become so. To reproduce this issue, you can create a simple python file, e.g.

rows = 3
cols = 2
b = [[1, 2], [2, 1], [0, 1]]
for i in range(rows):
    for j in range(cols):
        b[i][j] += 1

Set a breakpoint at the last line, watch 'b' (expanding its members) and step with require'dap'.continue(). Using C++ coupled with lldb-vscode requires a similar setup.

[rcarriga]

OK I've fixed the issue for Python anyway and believe it'll fix the lldb-vscode. Let me know if not 😄

[igorlfs]

Hey, thanks for fixing the issue with debugpy! Unfortunately, I'm still having the issue with lldb-vscode :(

I can record a demo if you think that it would be helpful.

[rcarriga]

OK I don't use C++ but managed to reproduce it with Rust (forgot they used the same adapter). I believe this is actually an lldb issue but managed to find a workaround. Please try the latest commit

[igorlfs]

Please try the latest commit

Apparently it's working but I still want to investigate a little further. I think under some circunstances a visual glitch may happen where a collapsed entry expands, overlaping with the actually expandend entries (I'm unsure how to reproduce this). Feel free to close this issue though, as I think this behavior is unrelated and the main problem I had was solved. Thanks for the amazing job :)

I believe this is actually an lldb issue

Should I file a bug report on llvm's repo?

[rcarriga]

I think under some circunstances a visual glitch may happen where a collapsed entry expands, overlaping with the actually expandend entries (I'm unsure how to reproduce this)

If you turn on nvim-dap debug logs and see it happen again, I should be able to spot the cause. Happy to keep open for a while anyway.

Should I file a bug report on llvm's repo?

You could but it's a weird bug and I didn't try reproducing with the CLI (which I imagine they'll want). I wasn't able to reproduce with VSCode either. The issue occurring was that the adapter was responding to the variables request of the list element (in your screenshot c[0]) with no variables meaning they are empty whereas it actually has c[0][0] and c[0][1]. This only happened after stepping once, and then it would respond with the correct data for following steps. It was pretty odd. Once I get a bit of time I could try put together a reproduction

[igorlfs]

I've managed to find a way to reproduce the aforementioned visual glitch:

1. Set a breakpoint and start a debugging session normally
2. Add a variable to the watch list and fully expand it
3. Add a second variable to the watch list, but only toggle it's first layer, eg
   
4. Step through the code such that the second variable's collapsed members change. Now you get this:
   
   Here's the nvim-dap log

[rcarriga]

Thanks for that, I was able to reproduce. I haven't had the time to figure out the issue but will take a look when I can

[rcarriga]

OK should be working now 😅

[igorlfs]

Everything is working perfectly now, thank you!