This is a mess, with a load of duplication, but it's a step. When you
request a breakpoint, we add one (in state ENABLED). You can then toggle
it again to change to DISABLED. And once more to delete it.
Once we start the debug server, that all changes and we just start
sending the breakpoints directly to the server and updating based on the
responses. This is far from ideal and somewhat jarring, but this
approach allows me to play around with ideas about what the user
experience should look like.
For line-breakpoints we already know it, so just use what we said
originally. For method breakpoints, we have no clue. While some servers
return a line, it could be in any file, so we just ignore them.
This change refactors the way we launch the job and puts it all in an
internal namespace. Having done that, we are able to launch the job from
the python side. This allows us to neatly load a json file, simlar in
format to .vscode's launch.json, but sufficiently different that users
won't just expect the launch.json to work.
This change allows selecting between 2 different adapters to debug the
same c program.
This also moves all handling of message dispatch to the connection
object. That seems fine and the requirements of a "handler" are:
- implement OnEvent_<event> for any unsolicited events
Otherwise, requests are handled still by callbacks.
Maintain the variables in a simple tree and allow the user to
expand/collapse in the dumbest way possible. This means we don't
recursively consume all of the possible variable scopes.
This displays the entire hierarchy in a window. This is about as
inefficient as could possibly be, but for trivial things allows you to
see the variables at least.
UI is totally placeholder
Step over/step in are the only supported commands
Hardcoded launch config using a specific debug adapter that happened to
work
Adds a trivial log file hack and fixes the protocol handler for bytes
Very very basic inital checkin to show a way to talk to/from a Vim job
using python (mainly), and to parse the sort of messages that LSP and
VSCode debugger protocol speak (i.e. similar to http messages).
Very hacky, sort of holds together for what it is.
