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)
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
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.
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.
