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.
Neovim does not raise:
* KeyError when accessing a vim dict
* KeyboardInterrupt when ctrl-c at a prompt
Instead it raises some internal subclass of vim.errro which cannot
easily be identified, so we just catch any vim.error.
Initially I considered using #i, #s, etc. to coerce to specific types,
but then it wasn't clear of the semantics (particularly for bool, where
JSON bool true/false, Python bool True/False).
But it turns out that we can just coerce any key from a JSON string.
Users can _probably_ type JSON strings for most things, or use variables
to run scripts to generate them, this allows essentially complete
flexibility to define the data types needed to populate the launch spec.
The purpose of this is to allow some level of automated setup by
requesting data from the user and then (subsequently) saving the
flattneed config to the vimspector config file.
This adds a --upgrade option to install_gadget.py and makes
VimspectorUpdate only update things which have changed.
To do this, we record the gadget spec in a manfiest file and compare it
with the current spec when in upgrade mode.
'Changed' in this case means that the gadget spec has changed from the
last time the installer was run. It does _not_ actually check the
presence of the gadget.
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.
