The current python integration works by having a python interpreter interact with neovim, instead of the python interpreter being in-process. [EDIT: All python code runs in this interpreter.] This is what I call a "host". It provides functions that implement this API:
:python // executes python code, eg: :python print 1+1
:pyfile // executes a file, eg: :python pyfile test.py
:pydo // applies a python expression on a range, eg: 1,2pydo return int(line)+1
pyeval(...) // returns the value of ..., eg: :echo pyeval("1+1")
A ruby-host would have similar functionality, for example, as would a scheme-host, etc. You name it. My proposal in the tracker was to allow such host-plugins to define the equivalent ex commands and viml functions instead of hardcoding them in neovim itself (like it currently does for the python integration commands and functions). This is currently difficult because of some limitations in vim's structure.
A go host, however, would possibly need to work differently. The idea for now is to have a process that checks for go files in a folder, and bundles them into a big executable that registers external functions in vim like a dynamic host would.
Nothing in the above means a plugin couldn't simply talk to neovim by itself, without using the host architecture. All a plugin needs is to talk to neovim thorough the msgpack-rpc api.
> I know that the plugin API is still in flux, but I really wish it was documented anyway. Actually, I'm not even sure how anyone was even able to start coding something like this without a design doc existing first.
Agreed. That's the goal of that discussion (I believe), to come up with a good design.
Another approach would be to choose a client server architecture but this is probably faster done in a separate project. But the idea would be that we have something like an editor core that exposes a SMALL API (e.g. "change cursor position to x/y", "insert 'foobar'", etc.) in a well-defined protocol.
On one hand you can then implement the famous VIM UI on top of that (i.e. in the tty sense, a curses program that communicates with the server, sending stuff like "change word") and on the other hand it is really easy to make it scriptable in any language that supports sockets. Obviously the networking/parsing stuff would be hidden by a neovim <LANG$> module.
Obviously this would be a multi-process architecture but the number of processes would be really small and peanuts in a modern system.
But anyway, thanks for your work!
> My proposal in the tracker was to allow such host-plugins to define the equivalent ex commands and viml functions instead of hardcoding them in neovim itself
Defining methods via msgpack-rpc and calling through vimscript is already possible(send_call will block until the connected plugin returns a response). Here's what Neovim still needs:
- Modify vimscript to enable definition of lower cased functions and commands, and commands that accept heredocs. This will let us move the knowledge about other languages/interpreters from the C core to vimscript, though it has the disadvantage of introducing incompatibilities with vim in the future
A go host, however, would possibly need to work differently. The idea for now is to have a process that checks for go files in a folder, and bundles them into a big executable that registers external functions in vim like a dynamic host would.
Nothing in the above means a plugin couldn't simply talk to neovim by itself, without using the host architecture. All a plugin needs is to talk to neovim thorough the msgpack-rpc api.
> I know that the plugin API is still in flux, but I really wish it was documented anyway. Actually, I'm not even sure how anyone was even able to start coding something like this without a design doc existing first.
Agreed. That's the goal of that discussion (I believe), to come up with a good design.