They moved the location of the main application.
But also:
- ignore multiple responses for the same request
- ignore protocol violations for variablesReference (assume 0)
- ignore protocol violations for missing 'name' (assume basename of
path)
Vim seems to insist that a buffer has at least one line. This means that
the first line set in the buffer object has to be a special case. Sigh.
Create a method to wrap that up.
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.
This introduced more hacks than it should. In particular, the sequence
about stack trace requesting became very messy. When we attach, we don't
instantly get a stopped event. This required making the Pause command
actually work (sort of). In this case we often won't have a proper
current thread.
Instead we sort of request all threads whenever we get a thread event,
thought his is horribly hacky and we should really just use the thread
event as-is. We then attempt to pause ALL threads on pause and continue
requests when we don't know the current thread.
Another issue is that when pausing it's likely we don't have the source
location info for the pause location (something like select() or
whatever), so we only set the current frame to the lowest one we have
source for. This sort of roughly matches what you want.
This whole thing makes it clear that threads and stack trace in separate
panes makes no sense. We need to replicate the hierarchy in the
variables view for threads and stack traces.
This is a huge hack, setting it manually and never resetting it. Just
displaying the value (no breakdown) etc.
I'm tempted to drop this functionality altogether as it is of limited
use when you have the locals and watch windows.
This actually restricts us to a single debugging pane, but that's really
already a restriction of the vim-side (only one job, etc.). Support for
multiple sessions isn't a priority.
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.
