This works only for things which have known variablesReference, so
particularly currently only for scopes and theoretically for members.
I think this can work for watches too. will need to check.
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.
It seems that the behaviour of the start parameter being missing is
server (or perhaps a specific client) dependent. The specification
clearely says that it should be inserted at the column of the original
request, but the servers clearly expect either for that column to be the
beginning of an identifier or for the client to ignore the spec and
request from that position anyway.
Reading the VSCode code, we see that the 'word' before the cursor is
guessed, and if only if BOTH 'start' AND 'length' are supplied, then
they are used to determine where insertion starts, otherwise the current
'word' is used. Unclear what 'word' means in the specific contexts, but
we're relying on iskeyword.
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': [ '.', '->', ':', '<' ]
\ }
This re-uses the OutputView code to run the installer script. Refactor
to remove connection from the base OutputView (and other places, it
wasn't used - only used after ConnectionUp).
This also consolidates the stdout and stderr buffers for running jobs.
The distinction was always arbitrary and probably an error, based on the
fact that they were separate in the APIs not based on usability.
This is the minimal required for a user to use conditional breakpoint -
we add an options dict to each breakpoint (line and function) and allow
the condition to be supplied. We add a plug mapping and a default
shortcut (<leader><F9>) to add one where we ask the user to enter the
condition and hit expression. This isn't great but it works.
We don't check the capabilities, so they would just be ignored if used
on a server that doesn't support them. We also ask for a hit expression
which most users won't understand so this isn't ideal either.
No tests yet.
