if_ruby compatibility / ruby provider

[mtortonesi]

It would be very nice to expand the scope of this project to include a ruby provider for neovim. Is there any plan to do that? If so, I would be willing to contribute.

[alexgenco]

Yes I think this absolutely falls under the scope of this gem. I've only put a small amount of time into piecing together how it would work, basically by looking at the python client and neovim source. I'd love some help on this front, since I don't have all that much free time at the moment.

[stephenprater]

@alexgenco I'm still working on it.

[alexgenco]

@stephenprater thanks for doing that. At the risk of stepping on your toes, I've added support for ruby remote plugin scripts, loaded from the rplugin/ruby directory. Here's the neovim-side change (as far as I know, haven't opened a PR yet) https://github.com/alexgenco/neovim/commit/3a552598dbd069c113bd166bab6db6cae991c321.

Is there any way I could track/contribute to your progress with the Ruby provider?

[stephenprater]

@alexgenco i haven't pushed anything yet. Seems like the update to 0.0.4 broke must of what I had done - I'm trying to get the remote host to respond to rpcrequests again.

There's actually a bit more to the neovim side than that - there's some stuff that has to be done within the C code to get it to work. I'll try to get something up tonight.

[alexgenco]

There were a lot of changes in 0.0.4, but I think the biggest changes were additive to support loading plugins. What kinds of failures did it introduce for you?

Are you sure there are C changes needed to support remote plugins? I've tested my branch of neovim against neovim-ruby master (not yet published to RubyGems) and plugin loading and spawning seems to basically work. The legacy ruby provider is another story, I still don't have a good idea of what changes that will entail.

[stephenprater]

You're right, I'm talking about the legacy provider. I haven't investigated, like... at all - but basically my remote host script no longer responds to RPC requests like it used to. I suspect this has to do with loading plugins in the script somehow, or perhaps namespacing the RPC requests, but again - haven't really looked to hard.

[alexgenco]

Yeah the host function name spacing is the likely culprit. Check out the acceptance test to see the format it expects for functions.

[bradurani]

Really excited this is active. Thank you so much for working on this :100:

[cstrahan]

I don't want to dissuade anyone from continuing their work on this front, but I'd like to also take a stab at this. Don't know when I'll have the time... but I'd like to take a stab at it tonight. If anyone has some work I can reference, that would be great.

I don't know about you all, but I find Command-T to be indispensable, but having Ruby embedded in vim causes me all sorts of headaches due to ABI problems when updating Ruby. I'd love to switch to neovim.

[stephenprater]

@cstrahan https://github.com/stephenprater/neovim/tree/add-ruby-ex-commands

After the neovim 0.0.4 update the host functions are name spaced. So - once we fix that, we just have to uncomment all the Lua tests and go back to it.

[cstrahan]

@stephenprater Cool - thanks! If I have anything to show, I'll drop a link here. If I can't finish it, hopefully whatever I find will be useful to others working on this.

[stephenprater]

@cstrahan if you want to make PRs against that branch, I'll merge them before I make my PR to Neovim.

I probably won't work on it tonight but I might get to it tomorrow.

[cstrahan]

@stephenprater Ok, cool. What's the current status of your changes? Is it mostly working, with a few gotchas?

[cstrahan]

Looks like a couple specs are commented out: https://github.com/neovim/neovim/compare/master...stephenprater:add-ruby-ex-commands

[stephenprater]

No - the neovim-ruby 0.0.4 update broke everything that I had previously done. I think it's function namespaces in the RPC requests that did it. The C-side stuff is pretty well done, but the Ruby provider itself is barely started.

There is (or was anyway) at least one fairly big missing feature from the neovim-ruby gem - which had to do with the way ranges are expected to be passed into the provider. If I remember correctly, and I'm not sure that I do - it's that there was no instance-level accessor for current_range.

[alexgenco]

@stephenprater I have preliminary range support on master: https://github.com/alexgenco/neovim-ruby/blob/5ddce88303a5565675074a13631ed74c15a6e443/lib/neovim/current.rb#L46-L53. Although it's probably not complete enough to be of any use to you yet. I can bump/release the gem later today if you'd like.

Welcome, @cstrahan :)

[mtortonesi]

Any progress on this issue? Is there any way I can help?

[stephenprater]

Sure - if you want to rebase that old branch and resurrect it, I think I finally did get it at least talking to the provider again. It's been a bit since I worked on it.

[stephenprater]

actually I found a few minutes, I'll rebase it and push it right now.

[stephenprater]

https://github.com/stephenprater/neovim/tree/add-ruby-ex-commands

So take a look at that branch, uncomment some of the Lua specs and go to town.

[alexgenco]

I was also planning on taking another crack at this tomorrow.

[alexgenco]

Still a ways off, but I've gotten a couple more tests passing. There is still some funkiness around nvim passing the range and neovim-ruby persisting it.

https://github.com/neovim/neovim/compare/master...alexgenco:master

[alexgenco]

Opened a PR in neovim https://github.com/neovim/neovim/pull/4980

[stephenprater]

Sweet!

[alexgenco]

This has been merged into neovim master: https://github.com/neovim/neovim/pull/4980