They moved the location of the main application.
But also:
- ignore multiple responses for the same request
- ignore protocol violations for variablesReference (assume 0)
- ignore protocol violations for missing 'name' (assume basename of
path)
The java architecture is a little different:
- the debugger is a jdt.ls extension bundle.
- to start the server, you send a startDebugSession command to jdt.ls
- this returns a tcl port to connect to for DAP
Loading of jdt.ls and the extension are out of scope for vimspector
currently and instead you can tell it to ask you for a port to connect
to.
After connexting to that port, vimspector works as normal.
To support TCP/IP was pretty simple: we provide the same API from
vimscript as the job-based (stdin/out) comms layer, but instead just
directly use a channel.
The only wrinkle was that the java debug adapter broke the protocol on
runInTerminal and didn't return a 'cwd', so we make one up.
We expand environment variables, ~ and workspaceRoot. The latter is to
match vscode and typical launch configs. As we don't know what the
workspeace root might be, we use the location of the .vimspector.json.
Like VSCode does, compbine console and stdout, and allow you to enter
commands in the console. It's all a bit janky right now and the
insertion point isn't ideal (as not all output is interactive) and some
output is asynchronous via a somewhat different channel.
This is starting to get horribly hacky and needs refactoring into
proper classes. Expandable variables now have the following additional
magic properties:
- '_expanded': True (expanded), False (collapsed), none = no preference
- '_variables': Current of child variables
- '_old_variables': The previous state of the '_variables' list when
refreshing
Remember that '_result' (the magic property of a watch expression) is
also treated like an expandable variable, so also has these magic
parameters.
Vim seems to insist that a buffer has at least one line. This means that
the first line set in the buffer object has to be a special case. Sigh.
Create a method to wrap that up.
The advantage of this one is that it has globals and statics in the
variables and runs directly in lldb. It can also show disassembly,
though we don't yet support that.
The disadvantage is that this is yet another plugin that plays fast and
loose with the protocol, so we have to add a bunch more gets.
This required working around some sort of bug where the server returns
an invalid content length. Either that or we are somehow processing the
same message twice with additional escaping? It's really strange.
This involves some horrible forceful reading on exit to ensure that we
get a response to the disconnect request. This ensures that any debugee
is killed cleanly.
