This adds some templates to the gadget config, organised by "category"
(human-readable) and presented in a menu. The configuration thus created
is just run normally through the variable replacements.
Also:
- Fix default value replacements which come from the calculus
- Add default-value _lists_. This uses select-from-list UI. Useful for
enumerated values. Allow specifying a default.
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.
Change lua test files to call `require 'lldebugger'` only when using
love, because it's not needed with lua or luajit. Also add `stopOnEntry`
key to test `.vimspector.json` because it works correctly with this
change.
It's quirky, we have to pass the stopped event to LoadThreads so that it
can correctly work out the state of any _newly_ added threads. We now
also correctly apply the allThreadsStopped=False behaviour where you
must not allow expansion of such threads (in theory, that's untested).
- don't clear the stack trace on continue - track running status
properly (ish)
- mark threads (running) when the app is executing
- indicate the "current" thread with a different icon
TODO:
- allow user to specify current thread?
- track running status of threads individually?
- allow to pause/continue specific threads?
