There are 2 things we ask for input for:
- input variables
- exception breakpoints
It's irritating to have to repeat yourself when going through the
edit/debug loop.
Howver, cacheing has some quirks and disadvantages - they key one being
when to clear the cache. To resolve this we take two slightly different
approaches:
1. For input variables, we remember the choice of the user, but present
that only as the default, so they can just hit enter to accept it. We
already rememeber the choices for the length of the debug session (i.e.
across 'restart' calls).
2. For exception breakpoints, we remember the choices for as long as the
current session is running.
This allows users to hit the 'restart' button without being prompted at
all.
Meanwhile, we also remove the (broken) support for exception breakpoint
matchers and state the server default for exception breakpoint filters.
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
