If you donated to Neovim, consider also donating to Bram's charity. All of us who have benefited so much, and for free, from Bram's efforts owe him thanks, respect and much more.
(I'm a satisfied Vim user and see no need for any major revision. Perhaps others with different needs feel differently, and it has been discussed before:
Just curious, how is this project being received by Bram Moolenaar, the creator (and BDFL I believe) of vim?
Just found an answer https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...
Basically GCC was falling behind, a fork called EGCS was a lot better after a while and at a certain point GNU just dropped the old GCC and adopted EGCS as the official GCC.
Of course, Neovim first has to make a release for this to happen. And Bram has to let go of the legacy platforms (sorry Amiga!). He can support them via older Vim versions, I don't think it would be a problem for anybody...
The title is okay within the context of the site it's on, but it's completely nonsensical on its own without that context.
However, it looks like the proposal for Go integration is very much Go-specific, following the example set by Python-specific integration code. This makes me significantly less excited about Neovim's plugin architecture, since it now seems to me like every language may need support to be manually added to Neovim anyway. What's going on here?
In regards to the Go integration, it's been decided it would be better to have a host like in the case of the python plugin, but the main rationale for that is not to create too many co-processes.
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.
: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 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.
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!
/update: just read https://github.com/neovim/neovim/wiki/Plugin-UI-architecture so it IS the chosen architecture - never mind then!
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:
- A way to spawn plugins through vimscript. This was fixed [here](https://github.com/tarruda/neovim/commit/acf17dbefef379ecb8e...) and will replace the initpython/initclipboard options. This alone will be enough to implement the golang proposal.
- 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 way to spawn plugins through vimscript. This was fixed [here](https://github.com/tarruda/neovim/commit/acf17dbefef379ecb8e...) and will replace the initpython/initclipboard options. This alone will be enough to implement the golang proposal.
This is neat.
Thanks for all the work, btw, tarruda. neovim is a great project, and you deserve a lot of credit for pushing ahead with it.
I've been avoiding to write documentation because the rpc infrastructure was still alpha, though that will probably change after #1130 is merged(I will write at least one comprehensive wiki entry)
> I'm not even sure how anyone was even able to start coding something like this without a design doc existing first.
This is just how I work: Instead of writing design docs, I start with an idea and the design is shaped while implementing the initial prototypes. Only after it's solid the docs will be created.
 - https://github.com/hraberg/deuce "Emacs under Clojure"
brew install --HEAD https://raw.github.com/neovim/neovim/master/neovim.rb
(I love conciseness.)