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?
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
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 adds the following options, allowing the default sizes to be
overridden:
- g:vimspector_sidebar_width: Controls the width of the left utility
windows (variables, watches, stack trace)
- g:vimspector_bottombar_height: Controls the height of the output
window below the code window
The terminal is typically created as a vertical split of the code
window. The following control the sizing of the terminal window used
for debuggee input/output when using Vim's built-in terminal.
- g:vimspector_code_minwidth: Minimum number of columns to try and
maintain for the code window.
- g:vimspector_terminal_maxwidth: Maximum number of columns to use for
th terminal, when vertically splitting the code window.
- g:vimspector_terminal_minwidth: Minimum number of columns to use when
it is not possible to fit g:vimspector_terminal_maxwidth columns next
to the code window with g:vimspector_code_minwidth columns.
We were trying to avoid equalalways from changing the UI layout by
unsetting it and resetting it after changes. However, re-setting
equalalways actually resizes all the windows, so this never worked.
Instead we judiciously use rightbelow, leftabove, etc. and specify the
exact window sizes we want.
As a side-effect we make the terminal sizing a little more pleasant by
default, ensuring that it is no wider than 80 chars, and tries to use
any remianing vertical space after reserving 80 chars for the code
window.
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.
