Problem: In non-code window, user see a '...' balloon even if python
knows it does not need to work
Solution: use pyeval in vim so that python's knowledge is getting back
from the stack as return value
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.
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 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.
This shows stack traces as children of a thread, removing one of the
UI splits. However, we still have the somewhat awkward concepts of
"current" thread and "current" stack frame. These are messy and
incredibly fiddly. And in any case, probably wrong _most_ of the time.
This is a huge hack, setting it manually and never resetting it. Just
displaying the value (no breakdown) etc.
I'm tempted to drop this functionality altogether as it is of limited
use when you have the locals and watch windows.
