next_message(timeout) gives NameError about pynvim HOT 5 CLOSED

I'm trying to integrate the nvim-client event handling with the event loop of IPython (for interactive testing/introspection of plugins). The simplest way would be to call next_message with a very low time-out

There's a push_message function created exactly for this purpose: It may be called from other threads(running different event loops for example) to generate virtual messages. Here is an example.

You should also read the tkinter ui script, which gives an idea of how to feed another event loop.(To run you need neovim/neovim#781)

TimeoutError seems unfortunably not be defined in python2.x. Perhaps define neovim.TimeoutError when running in python2?

👍 Will fix this now

Before writing any significant amount of code that uses the python client, keep in mind that it is still alpha so some APIs will probably change. One task I already have in mind: rewrite it using twisted(for pypy support) and greenlets(for simplified concurrency while still keeping the familiar synchronous API)

Also, the vim object could perhaps expose the fd of the underlying connection, that way the client could easily be efficiently integrated into any existing eventloop (by registering vim.next_message as callback for incoming data on the fd). (At least for my case that would be simpler than running the neovim eventloop in a separate thread)

As I said, the push_message can be used to run the event loop in another thread. you can run the next_message loop in a background thread if ipython event loop must be ran on the main thread

from pynvim.

Thanks for the pointers. The next_message(timeout) usage was only temporary to integrate with the IPython terminal application (which doesn't have a proper loop, I think they just monkey-patch libreadline into calling a specific pyfunc X times per secound) Soon I will only use the IPython remote execution protocol, which is designed for async operation and will be straightforward to integrate using the push_message pattern.

I'm fully aware of the alpha status, in fact the main motivation was just to test the api and figuring out missing pieces. An IPython client is interesting in this stage I think, since it will implement async completion, live object introspection/documentation and other such "code intel" features. The fact that it almost is ready for real use for me and is much more responsive than vim-ipython (at least in my test cases) is just a pure bonus. (for instance it already supports async stdout and code completion). If this "alpha stage" api already enables this much, I can only imagine how awesome it is going to be when it is getting closer to "stable". 👍

from pynvim.

@bfredl After the refactor the library should be more stable(it is still should be considered alpha though, at least until I fill some gaps in nvim plugin handling).

I still need to write some high level documentation but here's some updates:

• vim.push_message is now vim.session.post(event_name, args...).
• vim.next_message is now vim.session.next_message() and it no longer receives a timeout. It should be easy to emulate a timeout by using a combination of threading.Timer with vim.session.post

from pynvim.

The post method was broken so the timeout emulation probably wasn't working when I posted the comment. Just pushed a fix and published to pypi, here's an example of how you can do it:

from threading import Timer
t = Timer(5, lambda: vim.session.post('timeout'))
t.start()
print vim.session.next_message()

from pynvim.

Thanks, will try this out later.

from pynvim.