This puts the 3 utility windows at the top, horizontally split, with the
code view below. The terminal window is drawn either vertically split
(if there's room) or horizontally split otherwise. The output window
remains at tht bottom.
We add equivalent sizing options too, setting some defauts that roughly
work on my macbook pro.
We try to guess the best layout to use. In particular we go into
'narrow' mode if there are not enough horizonal columns to fit the
sidebar, code and at least the minimum terminal size. We also try to
move the terminal to be horizontally spit (i.e. vertically stacked) if
we can fit the max number of lines, but only the min number of columns.
This is all a little heuristic, but when testing it myself, it feels
good and tends to pick a good option by default. Users can always
customise the ui mode (g:vimspector_ui_mode and all the various specific
width options)
The VimspectorEval command used `-bar` but this prevented the use of double quotes. This seems much more useful than a vim comment in this scenario, so remove the `-bar`.
This is _techncially_ breaking change, but I don't think it's likely anyone will be relying on doing `VimspectorEval x | something else`. If they are, sorry.
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.
Change lua test files to call `require 'lldebugger'` only when using
love, because it's not needed with lua or luajit. Also add `stopOnEntry`
key to test `.vimspector.json` because it works correctly with this
change.
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
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.
