WIP: basic coroutine and subprocess support

[bfredl]

Work towards #342

The model supported here is: plugin code is written as greenlets ( spawned as request handlers or nvim.async_call), but once in a while needs to invoke a coroutine defined by some library (such as asyncio itself). This model is enough is to use the io facilities of asyncio, which mostly uses raw callbacks.

nvim.run_coroutine(coro) will spawn an asyncio task and suspend the current greenlet until completion and return the result. If you don't care about the result you can still use the non-blocking asyncio.ensure_future(coro).

A simple example to suspend the current handler for some time (NB: will block nvim if the handler is sync):

c = asyncio.sleep(3)
nvim.run_coroutine(c)
nvim.command("echomsg 'done'")

As a convenience a wrapper for the subprocess protocol is also added, which wraps the data handler in a greenlet (so that it can use nvim requests):

def on_out(fd, data):
    nvim.out_write(data)

def on_exit():
    pass

transport = nvim.start_subprocess(['echo', 'test'], on_data=on_out, on_exit=on_exit)
# transport.write(b'bytes')

[Shougo]

I have tested it and it works.

But

nvim.run_coroutine(c)

It must be nvim.run_coro(c) instead.

[bfredl]

I forgot to push the last fix. I also fixed stdin capability: start_subprocess returns transport with .write() method.

[Shougo]

Ah, OK. Thank you for the fix.

[Shougo]

Hm....

I have tested it. The sleep works, but in subprocess cannot access neovim until RPC is finished.
It is intended behavior?

[Shougo]

As a convenience a wrapper for the subprocess protocol is also added, which wraps the data handler in a greenlet (so that it can use nvim requests):

Hm. This is needed.

[bfredl]

The sleep works, but in subprocess cannot access neovim until RPC is finished.

@Shougo What is the situation more specifically? If the parent python process is in a sync handler, the child cannot connect until the sync handler returns.

[Shougo]

Shougo/denite.nvim#624

In the branch start_subprocess works?
The subprocess must use nvim object.

The sample seems use nvim in only on_out handler.

[bfredl]

The subprocess can use nvim, but for now it has to connect on its own using $NVIM_LISTEN_ADDRESS. I don't think a socket handle can be duplicated in a portable way (I think libuv can transmit a handle over a socket, but it will basically be: on linux do X and on winNT do Y).

[Shougo]

@Shougo What is the situation more specifically? If the parent python process is in a sync handler, the child cannot connect until the sync handler returns.

Yes. But in nvim.run_coroutine(c), cannot free the lock?

[bfredl]

This is a bit tricky, parent and child python cannot collectively "own" the nvim focus, only one channel can be blocking at a time. For now it has to be async. We can of course add this ability, but it will need more code in nvim core.

[Shougo]

For now it has to be async.

Yes, ui branch uses async RPC. But it is not perfect.

We can of course add this ability, but it will need more code in nvim core.

OK. So I wait it.