The example was was using 'launchCommand' which is not valid according
to the schema; it should be 'runCommand'.
But also, it never really worked. Vimspector would start the "adapter"
(in this case, try and connect to the TCP port) before running the
"prepare" commands, wich in this case would actually start debugpy
listening. So to solve that we run the prepare commands earlier.
Hopefully this won't cause a regression for Java and C++ remote attach,
which we don't really have tests for.
Finally, due to the way docker works, when you forward a port and
nothing is listening on it, docker _accepts_ the connection then
immediately drops it. This is _super_ annoying meaning that it looks to
vimspector liek the server instantly dies if it takes nonzero time for
the remote commands to open the port. So to solve this we add loaunch
and attach delays which can be configured in the adapter config. This
actually solves a prolem where the java debugger just takes agest to
attach on remote launch too.
(Finally, finally...) updated the vimspector schema to represent
the real launch/attach remote configuration, which was incorrectly
spec'd at the adapter level, but it's actually per launch/attach block.
We add a 'temporary' option to line breakpionts and try and clear any
temporary breakpionts on the line we end up stopping on. This might not
be art, but _probably_ works in almost all cases that matter.
it's a bit hacky the way we have to push the reason around, but we don't
know where we stopped until we actually get the stack trace response and
SetCurrentFrame
Move temporary breakpionts to match server response
Also delete any existing ones when adding a new one and add tests for
run-to-cursor.
Only continue after we successfully set the breakpoints. This makes it
work in go
Initially I considered using #i, #s, etc. to coerce to specific types,
but then it wasn't clear of the semantics (particularly for bool, where
JSON bool true/false, Python bool True/False).
But it turns out that we can just coerce any key from a JSON string.
Users can _probably_ type JSON strings for most things, or use variables
to run scripts to generate them, this allows essentially complete
flexibility to define the data types needed to populate the launch spec.
The purpose of this is to allow some level of automated setup by
requesting data from the user and then (subsequently) saving the
flattneed config to the vimspector config file.
Debate rages about whether JSON should have comments. The specification
says it shouldn't but the author of JSON suggested that if you want to
use JSON for configuration, then pipe it through jsmin before parsing.
So that's what we do, using a tiny JSON minifier from
https://github.com/getify/JSON.minify/tree/pythonCloses#135
There are 2 things we ask for input for:
- input variables
- exception breakpoints
It's irritating to have to repeat yourself when going through the
edit/debug loop.
Howver, cacheing has some quirks and disadvantages - they key one being
when to clear the cache. To resolve this we take two slightly different
approaches:
1. For input variables, we remember the choice of the user, but present
that only as the default, so they can just hit enter to accept it. We
already rememeber the choices for the length of the debug session (i.e.
across 'restart' calls).
2. For exception breakpoints, we remember the choices for as long as the
current session is running.
This allows users to hit the 'restart' button without being prompted at
all.
Meanwhile, we also remove the (broken) support for exception breakpoint
matchers and state the server default for exception breakpoint filters.
