bfredl

> though wouldn't there be a backwards compatibility problem? Yes. It would need be a separate project from this. I wouldn't even think "fork", rather new codebase which can happen...

These should mainly be documented in `remote_plugins.txt` in nvim core, as these behaviors are shared between hosts. But then we should of course add an appropriate link from this repo.

Should it just be moved to `setup_logging()`? The pynvim host should set up logging, but pynvim as a lib should leave that to the app using the library.

> I wonder if we should not use asyncio before python 3.6 @justinmk Except that it says "before 3.5.3". Distros should supply bugfix releases even if they are stuck on...

Hmm, it looks like nvim methods are invoked directly from a separate thread, that is definietly not safe.

> Can you provide more insight with regard to your last comment? I don't think I can. Deoplete doesn't use threading anymore.

the code ``` class MyPlugin: @neovim.autocmd(..., sync=False) def my_async_cmd(self): # This obviously doesn't work because the function is async code = self._vim.current.buffer[:] ``` should actually work. Using `threading.Event` should only...

Plugin defined functions and commands must begin with uppercase. But we should throw an error for this as early as possible, ideally by nvim core so it covers hosts in...

Yes, method calls should be avoided in `__init__`, as the plugin has no control when it is run. Perhaps we could detect this and show a better error message.

It's a pity they don't support windows. There is this PR https://github.com/MagicStack/uvloop/pull/62 but no idea if/when that is going to happen...