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.
UI is totally placeholder
Step over/step in are the only supported commands
Hardcoded launch config using a specific debug adapter that happened to
work
Adds a trivial log file hack and fixes the protocol handler for bytes
Very very basic inital checkin to show a way to talk to/from a Vim job
using python (mainly), and to parse the sort of messages that LSP and
VSCode debugger protocol speak (i.e. similar to http messages).
Very hacky, sort of holds together for what it is.
