Sometimes it can take quite a while to start up and initialise the debug
adapter. So we use popup/float to display the status as we start up and
shut down.
This increases minimum Vim version to 8.2, but that's been out for ages
now and I intend to agressively require latest/later vim/neovim
versions.
neovim's termopen() replaces the buffer object in the current window
with a terminal, internally, this completely breaks the buffer list.
Repro:
* Create test.vim:
```
vsplit
call termopen( '/bin/bash', { 'cwd': getcwd() } )
call bufload( expand( '<sfile>' ) )
```
Then:
* `nvim -Nu NONE test.vim`
* `:source %`
Error is "Invald buffer name 'test.vim'"
Anyway, the correct thing to do is to create a _new_ buffer before
making it into a terminal (vnew, new) rather than a split of the current
one. This was only working before because the CodeView window never had
any buffer in it and was broken by the change to use the current buffer
when staring debugging.
Fixes#131
In Vim, the vim module is always imported by magic in the global scope,
but the docs suggest that you're supposed to import it anyway.
In NeoVim it's never imported so we were relying on some other plugins
having already imported it.
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.
