Reading about neovim is very cool. It's nice to see such an actively beloved open source project which is all about modernizing an old tool (and that means 90% "backend" stuff), and it's a big breath of fresh air to see how well organized they are.
Agreed. When the initial fundraising campaign was happening I figured it was just going to fizzle out eventually when the guy driving it got bored. Boy was I wrong... this is a seriously organized effort.
Very glad you guys feel that way! To anyone at all interested and having some free time, feel free to see if you can contribute something at https://github.com/neovim/neovim. Anyone is welcome to help out.
aktau (commented below), Justin Keyes, and obviously Thiago are certainly driving a ton of the development. The amount of time they put into the Issue tracker and coding blows me away. It's all really impressive and they definitely have set the tone for the project.
Most importantly, thank you Bram Moolenaar! Vim is the probably my most productive tool and it's certainly my favorite.
If you donated to Neovim, consider also donating to Bram's charity.[1] 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:
https://news.ycombinator.com/item?id=7287668 )
Unfortunately, it's been a few months since he last wrote that answer. Would be great to hear what he thinks about it now. I don't think anyone expected such success (based on what they have accomplished so far in terms of development).
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...
Reading through the Github proposal for Go plugin integration, I'm pretty confused about Neovim's plugin architecture. I had thought that Neovim's plugins would be language agnostic, with external processes communicating with Neovim using msgpack-rpc (presumably paired with some method of telling Neovim to start those processes).
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?
No, the architecture is still pretty much language agnostic. My `providers` branch[1] generalizes the python integration, for example. I discussed the possibility of plugins building on this to provide the equivalent functionality to the current python implementation.
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.
Okay, it sounds like my fears are unfounded, but I still don't really understand it. What is a host in this context?
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.
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
> I know that the plugin API is still in flux, but I really wish it was documented anyway
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.
Even though the plugins communicate over msgpack-rpc, there needs to be integration to support the best way of finding and executing them. There's a lot of debate in the discussion between a process-per-plugin approach like you assumed (and like the proposed go plugin interface implements) and a plugin-host approach where a single process runs all of a given language's plugins (like the python plugin interface implements).
I'm really looking forward to seeing neovim make it possible to put it in a nice GUI. I know it's an application that meant to be used with the keyboard, but gVim always refuses to behave in maximized windows, doesn't handle random window widths, etc. Is there a good workaround while this dream is coming true?
The GuileEmacs project never really getting off the ground with much momentum is probably the only reason I still use Vim. ELisp just kills any motivation I have to 'make emacs my own'.
Is there any way to link to neovim as a C library instead of using the messaging protocol? Also, where is the documentation of the protocol? I wasn't able to find it after a few minutes of browsing.
Totally off topic but this reminds me that I need to see if I can figure out how to get Nvi to compile on OS X Mavericks. I know, I know, but it has a special place in my heart because it was the first version of Vi that I ever used.
The project seems intent on keeping the build and distribution processes up to date along with the evolving codebase. For example, you can install now via Homebrew:
