The problem was that the python regex engine is strictly left-to-right,
so matching `[^}]|\\}` against \\}} meant that the `\\` was consumed by
the left of the `|`. The solution is to just switch them around.
Also add a way to run python tests from within vim, so we can actually
test this stuff.
The problem is the sequence of events sent by the debug adapter.
Vimspector requests threads:
* When the initialisation exchange completes (requests all threads)
* Whenever a thread event is received
* whenever a stopped event is received.
If any of those happens while any other request is in progress, we cache
the request and handle it later. The latest request is processed when
the response to the outstanding request is received.
The problem is if the event is a stopped event, it is the handling of
the threads request that actually sets the thread state internally to
stopped. In a sequence where the first event is a stopped event, we end
up discarding the stopped event. like:
1. Stopped event (thread 1 = stopped) (request threads)
2. Initialisation complete (cache request)
3. threads response received (discard response and process cached request)
4. response received (but forgotten about the stopped event).
The solution is to always process the thread response, even if we send
the cached request. To avoid flicker, we don't draw the screen, or
expand any threads/stacks in the case where we're sending a cached
request.
1.2.1 is, as of this commit, the most recent version of the gadget.
The version currently used, 1.0.0b12 is not compatible with Python 3.9:
the build errors out on missing arguments for _PyEval_EvalFrameDefault.
Python 3.9 is the version of Python that will be shipped with the
upcoming debian release.
Support for 3.9 was merged in before the final 1.0.0 version. So,
upgrading the gadget will bring in python 3.9 support
When installing a custom gadget not officially supported by vimspector the
default extension path is 'extension', this works for vscode extensions but
does not support some debug adapters. This commit gives the ability to change
that default extension path by specifying 'extension_path' within the gadget
installer file.
Installing 'cust_adapter' would use the extension path 'adapter' rather
than 'extension' (ie ${gadgetDir}/cust_adapter/${version}/root/adapter)
{
"cust_adapter": {
"download": { ... },
"all": {
"extension_path": "adapter",
"adapters": { ... }
}
}
}
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.
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?
