neovim support?

[jeff-dh]

Hi,

I just came across this plugin and it looks awesome so far. I tried to run it with neovim and it did not work out of the box (first issue _vim.Function is not available in neovim).

I was wondering whether it would make sense to 'port' it to neovim or make it neovim compatible and how much work it would be. On the first glance it seems feasible replacing _vim.Function with some home-brewed solution, but I've no clue what's gonna come up next.

Do you know what else is missing and do you have an idea how much effort it would be?

Do you have any ideas, plans, opinions about it?

[paul-ollis]

Hi Jeff,

A very well timed question because I have not looked at this project for many months. (It is not dead. I have just been very busy and this has fallen down the priorities list.)

Compatibility with neovim has been something I have (long term) planned to look at. I have not, until today, actually looked at the practicalities. Based on a quick (last couple of hours) investigation I (cautiously) think:

• Yes, it should be possible.

• I think the major stumbling block is the Vim 7.4, Python-interface features that neovim does not support.

  • vim.bineval
  • vim.Dictionary
  • vim.Function
  • vim.List
  • vim.Function (as you have discovered).
  • vim.vars, vim.vvars and the corresponding Window and Buffer object attributes.
  • vim.Tabage

  Plus there are probably some behavioural changes that VPE currently relies on.

• I think it is probably worth the effort. If you are able to able to assist then it might be possible to implement the changes fairly soon.

I need to spend some more time investigating, but I can foresee some important design decisions will be required. One that immediately springs to mind is:

Should VPE work with the existing pynvim module (vim 7.3) interface or
would extending pynvim to match vim7.4 be a better approach?

I currently have no real opinion on this. I am also aware that pynvim
provides alternatives (such as the 'vim.api' object) that may support
a cleaner approach.

[jeff-dh]

Whether to use the existing pynvim interface or extend it.... well that becomes pretty big... I guess it's not only pynvim but the whole python interface / support in nvim.

I found the following issues:

https://github.com/neovim/neovim/issues/1898 https://github.com/neovim/pynvim/issues/411

So my assessment from reading those two issues is, that "extending pynvim" is not an easy task....

What kind of assistants are you looking for? I'm not really into the 'low level' api stuff of pynvim / vim / nvim, I got a rough idea of what approximately must be going on there but..... and since this issue seems to become bigger than working around couple of calls I'm not sure how much I can assist you, I don't see to get myself into the details of nvim python api hacking....

[paul-ollis]

I have only skimmed those 2 issues, but think your are right that extending pynvim is probably not the way to go.

I have had a quick play and quickly reached the point where the VPE plugin loads without complaint, by pretty much providing stubs for:

• vim.Buffer
• vim.Dictionary
• vim.Function
• vim.List
• vim.Range
• vim.TabPage
• vim.Window

It should be possible to convert these stubs to implementations that emulate the behaviour that VPE depends on, but I do not yet have a good feel for how much effort is required.

The next most road block is that Nvim does not supoprt the --servername option and corresponding functionality. My tests are almost entirely reliant on this feature. To make further progress I will need to allow the tests to be able to use a suitable Nvim mechanism as an alternative. Probably not a big deal, but not a job for today.

If I can get to the point where the first (server control based) test is running, I will create a neovim branch.

It will be interesting to see how the performance compares to Vim.

[jeff-dh]

That sounds pretty good so far.

Let me know when you created the branch, I'll have a look at it..... maybe I can find an easy stub and assist a little if you like.