* We enter the popup window
* some log data is received, so we update the log buffer and jump to the
log window to scroll it
* meanwhile, the WinLeave auto command on the popup window fires and
closes the popup window
* Having scrolled the log window, we try to jump back to the popup
window, which by now has been closed.
Fixes#390
Confirm now takes the list of options, list of keys to select them and
the default value. Returned values are always a 1-based index into the
list (like SelectFromList) or -1 to mean esc/ctrl-c.
This uses a nice popup dialog in vim and a crappy input on neovim.
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.
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'.
