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)
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.
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.
Fix restarts always getting stuck "Initializing" when using CodeLLDB.
When using the restart command we re-use the configuration dict as-is,
so always re-use the same TCP port for the lldb socket. Originally it
was thought this was due to a race condition, having the port still
open, but it's not.
When doing a restart, or reset, we shut down the server after we get the
response to the disconnect message. CodeLLDB then also sends a
'terminated' message.
Previously we were forcefully closing the socket before killing the app,
after we get the 'disconnect' response. This meant that the OS buffer
for the socket to localhost:<the port> still contained the terminated
message at the point that we force-closed the socket and killed the
server.
The result was that the firt messages read from the "new" socket to
locahost:<port> were the last messagse written by the previous process,
trikcing vimspector into thinking that the server terminated the process
(before responding to the initialize request).
ANyway, the solution is to ensure that we read all messages from the
previous instance before considering it done. This is done by killing
the server if there is one *first* and then trying to read any messages
from the socket until it closes (reads EOF).
The tricky part is for when we didn't start the server (i.e. in a
multi-session setup). Here we simply _have_ to close the socket because
we can't know when we've received all of the messages, and we shouldn't
expect to receive any 'terminated' events after 'disconnect'.
