Again, the neovim API is lacking - we have to hack around our own retry
loop (where vim offers 'waittime').
Note neovim documentation says that it returns 0 on connection failure,
but actually it throws an error, so we catch that. There are probably a
ton of other problems with error handling, but i'll rely on user
testing/feedback for that.
Neovim doesn't allow you to replace a terminal buffer if the buffer has
received some output, so we tell it that the buffer is not modified as a
hackaround.
Fixes#154
This is the minimal required for a user to use conditional breakpoint -
we add an options dict to each breakpoint (line and function) and allow
the condition to be supplied. We add a plug mapping and a default
shortcut (<leader><F9>) to add one where we ask the user to enter the
condition and hit expression. This isn't great but it works.
We don't check the capabilities, so they would just be ignored if used
on a server that doesn't support them. We also ask for a hit expression
which most users won't understand so this isn't ideal either.
No tests yet.
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