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?
Change Dockerfile to install lua, luajit and love and also to install
nodejs 12 needed to build the lua debug adapter. Create the
love-headless test in support/test/lua to test love without an x server.
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
These are useful for running tests (i.e. ensure there's a breakpiont at
the start of the test) and/or other programmatic usages.
They will also be needed for setting temporary breakpionts.
Few problems:
- we were passing a dict instead of a list of breakpoints
- if the breakpoint had a source which was {} we crashed
- we didn't support the 'removed' event
Vim only renders a single sign-per-line. If we have the PC _and_ a
breakpoint, we should make that clear. Do this using a vimspectorPCBP
sign which combines both vimspectorPC and vimspectorBP (sort of).
We can't (unfortuantely) render the breakpoint blob in a different
colour, but it's at least obvious when we toggle on the PC line.
Add omnifunc for prompt buffers
This synchronous completion can be used with any completion system
including built-in CTRL-X CTRL-O.
The filetype of the prompt buffers is set to VimspectorPrompt so that it
can be identified by completion systems. For example, this works well
with YCM:
let g:ycm_semantic_triggers = {
\ 'VimspectorPrompt': [ '.', '->', ':', '<' ]
\ }
Too many plugins use the default priority of 10 so they race/chase.
Allow uses to configure the priorities and make sure that the defaults
are documented.
