A fork to support Vim-with-channels

[critiqjo]

Basically, these 3 files have to be re-implemented:

• autoload/lldb/remote.vim: This is responsible for sending all events to the backend. This needs to be replaced with something which encodes these events in json and sends it to backend.
• rplugin/python/lldb_nvim/__init__.py: This is the listener in the backend. This needs to be replaced with a listener which understands json from remote.vim.
• rplugin/python/lldb_nvim/vim_x.py: This in the backend is what tells Neovim to take all sorts of actions. This needs to be replaced with:
  • A sender in the backend which encodes these actions to be taken in a json format and send it via the channel.
  • A listener in frontend (implemented in VimL) which listens on the channel and makes sense of the json messages received.

Note: There is only one RPC-like interaction from Neovim where it waits for a "response" for a "request" it sent and that is for auto-completion. Everything else is event-based, that is Neovim gets notified of stuff from backend. But RPC-like calls from the backend to Neovim are used extensively (wherever you see async=False and use of a Queue in vim_x.py like this).

PS: I'm not planning on implementing this. If anyone is interested, I would be happy to help.

[johncf]

I started this in a spur of the moment! I wasn't planning on this at first. I was actually trying to get GDB to work with Neovim. But debugging got a bit painful, so I thought to give Vim a try, and I gotta say -- Vim's channel/job API is much simpler and more flexible (at least imo). Debugging is a lot easier (due to flexibility). You can find it at https://github.com/johncf/gdb.vim

It was just a day's work, and it's not yet in working condition. There are a few more bugs to clear to get it into a barely working condition. But the good news is that the code is lot simpler. There's only a single thread which takes care of interactions from both the front-end and the debugger.

To try it now:

1. Clone gdb.vim
2. Do set rtp+=/path/to/gdb.vim in you vimrc
3. Go to the test directory
4. gcc -g -o ab ab.c
5. Open Vim: vim ab.c (./run.sh no longer works)
6. :GGsession new
7. :GGmode debug
8. The server should be dead now! :sweat_smile:

Nothing interesting can be seen in the editor either, but if you inspect the log file at /tmp/gdb.vim.log, you'd see a lot of activity. I'm going to take another long break. So feel free to poke around. A lot of it is marked as TODO, which should be easy once you know how pygdbmi works.

Note: This will not work in Windows, because it does not support select with files. (Can probably be made to work in Mac.)

PS: This is an alias of @critiqjo

[johncf]

Just in case someone wants to poke around, here are a few heads up:

1. The Gdb job talks to the Vim process via stdin and stdout for the most part using JSON messages.
2. But the [gdb]logs buffer is actually directly connected to the stderr of the process. So you can print(..., file=sys.stderr), sys.stderr.flush() (flush is important!), and see it in Vim. But if the process exits with an error, it probably won't be displayed in that buffer because it exits before Vim could read from the pipe. So replace buffer in this line to file to redirect stderr to a file instead.
3. If you want to just play around with the Vim's job/channel API instead (perhaps for a headstart), go here: https://github.com/johncf/vim-channel-test

[johncf]

Adding a try block around this line would probably fix the issue I pointed to in the above comment:

[...] if the process exits with an error, it probably won't be displayed in that buffer because it exits before Vim could read from the pipe.

The change could be as follows:

try:
    Middleman(vimx).loop()
except:
    import time, traceback
    traceback.print_exc() # print traceback to stderr
    time.sleep(2) # hope for vim to read

cc @lenfien in case you're planning to hack on it.