This is the minimal required for a user to use conditional breakpoint -
we add an options dict to each breakpoint (line and function) and allow
the condition to be supplied. We add a plug mapping and a default
shortcut (<leader><F9>) to add one where we ask the user to enter the
condition and hit expression. This isn't great but it works.
We don't check the capabilities, so they would just be ignored if used
on a server that doesn't support them. We also ask for a hit expression
which most users won't understand so this isn't ideal either.
No tests yet.
Like VSCode does, compbine console and stdout, and allow you to enter
commands in the console. It's all a bit janky right now and the
insertion point isn't ideal (as not all output is interactive) and some
output is asynchronous via a somewhat different channel.
This shows stack traces as children of a thread, removing one of the
UI splits. However, we still have the somewhat awkward concepts of
"current" thread and "current" stack frame. These are messy and
incredibly fiddly. And in any case, probably wrong _most_ of the time.
You can currently only add them, not remoove them and you have to pass
the expression in the function call, but once added the variable
breakdown works nicely.
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.
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.
