nvim-gdb icon indicating copy to clipboard operation
nvim-gdb copied to clipboard

Published 20 hours ago • verified publisher icon sakhnik

Feature Request: Make vim the owner of breakpoints and not the debugger

Open lanza opened this issue 1 year ago • 3 comments

When you use a debugger in an IDE the IDE itself is the entity that owns the breakpoints. So when you click in the gutter and add a little red triangle the IDE gets the breakpoint request and then forwards it to the debugger. When the debugger is stopped and closed the breakpoints persist. So when you start your debugging session again you maintain the same set of breakpoints.

e.g.

https://user-images.githubusercontent.com/12656790/224216886-113d735c-6cb9-409b-be26-63395e23db10.mov

It would be nice to have some sort of global vim variable that persists breakpoints. Even a file ~/.config/nvim-gdb/breakpoints.json might make sense.

lanza avatar Mar 10 '23 03:03 lanza

I thought about a buffer object in the plugin that holds the breakpoints so I could set them before launching the debugger. Personally I don't need persistent storage but won't argue against it :)

WuerfelDev avatar Mar 14 '23 09:03 WuerfelDev

Considering this idea would mean a big change. The plugin nvim-gdb doesn't do anything currently before any debugger backend is launched. So there should be another state added similar to "debug view" in IDE. I can think of strong arguments for keeping the plugin minimalistic. Moreover, I'm sure there is a debugger-specific way to just save the current breakpoints to a file, and then load them back another time.

sakhnik avatar Apr 27 '23 12:04 sakhnik

Moreover, I'm sure there is a debugger-specific way to just save the current breakpoints to a file, and then load them back another time.

Yea, that's what I was thinking. I have a cmake plugin where I do similar. I just cache a few things like the last launched target, the args you passed to the target, the last build dir, the last source dir, etc.

When I go to run another command I just reparse the json file and then rewrite it at the end of the function if it was changed. It's obviously inefficient but the timeframe for reading and writing a small json file isn't perceptible by a human user, so it's actually a nice perk to have an on disk file as your source of truth for persistence.

lanza avatar Apr 27 '23 16:04 lanza