consider pie for plugins

[natefinch]

see https://github.com/natefinch/pie

Instead of compiling-in plugins, you could use pie to run executable plugins using RPC over stdin/stdout of the plugin executable. Far more flexible than making people compile things in, they could just be dropped in place, and they can be written in any language.

[driusan]

Thanks for the link. I'll investigate when I get the chance.

But it's not clear to me: how would using pie be different from the current behaviour of invoking selected text with os/exec.Command on middle click and inserting it into the buffer?

[josephholsten]

I think the main reason neovim switched to this sort of plugin arch is to allow more metadata to be passed to the plugin along with merely selected-text-as-stdin, and more structured responses than stderr & stdout.

The canonical argument against the naive plugins is what inspired jwz's famous:

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.

I don't have anything particularly against pie to achieve this, but I'd rather work to support something like acme's fs api (or the neovim nvimfs inspired by it). Or investigate the msgpack rpc that neovim is developing so we can reuse their plugins. Of course for all I know, just swapping the gob codec for msgpack would let us use nvim plugins.

Regardless, I'd like not to use the gob codec at all, because then it'll be unnecessarily tedious to write plugins in anything than go. And if you're writing the plugin in go, it's hard to argue that there's any reason not to compile it in.

[natefinch]

Note that pie supports whatever codec you want for RPC. You just use the *Codec functions (such as StartProviderCodec) and pass in the function that creates the codec, so like here:

client, err := pie.StartProviderCodec(jsonrpc.NewClientCodec, os.Stderr, path)

StartproviderCodec takes in a func(conn io.ReadWriteCloser) rpc.ClientCodec so in theory you can use whatever encoding you like. There's an example python plugin doing json rpc here: https://github.com/natefinch/pie/blob/master/examples/python-plugin/plugin.py

[driusan]

Okay, I've finally had a chance to look into this a little more now that the basic functionality of de is getting closer to having everything I need.

My concern with this has always been that from my understanding using pie for plugins would require:

1. Designing an RPC mechanism for plugins and doing a good enough job of it that it would be stable and not constantly breaking other plugins with changes
2. Documenting it well enough that third parties can use it without too much difficulty.
3. Implementing it.

Step 3 was never a problem for me, I was concerned about the significant work of steps 1 and 2 for only the theoretical advantage of it being a better architecture where plugins would still be tied to de.

Now that I've looked into it, I think those concerns can be sidestepped by using pie to implement support for the neovim plugin architecture, which would neatly sidestep my first issue and have the significant benefit of increasing the number of plugins that are available instantly.

Since I'm not sure if this plan will work and the neovim plugin plugin is probably going to be fairly complex and experimental at first, I might try it in another repo, but that's my current plan.

If anyone has any neovim plugin examples (preferably simple ones) that they'd like me to try, let me know.

[aeosynth]

go 1.8 officially supports plugins:

https://golang.org/pkg/plugin/

[driusan]

See my second comment in #40 for the problem with using the go 1.8 plugins. The fact that they're Linux-only is a fairly major stumbling block for me.

Since I've obviously been slacking off on this front, if anyone wants to look into adding Go 1.8 style plugins they may want to start by looking into github.com/sbinet/plugs as a method to build/load them.