

Issue #3 – Better Late Than Never - bpierre
http://neovim.org/news/2014/sept/

======
scrollaway
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.

~~~
xienze
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.

~~~
aktau
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](https://github.com/neovim/neovim). Anyone
is welcome to help out.

------
hackuser
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.

[1] [http://iccf-holland.org/](http://iccf-holland.org/)

(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](https://news.ycombinator.com/item?id=7287668)
)

~~~
unclebunkers
Just curious why no love for ol Bill Joy?

~~~
fritzo
And Tim Thompson

------
phireph0x
As a vim user for many years, I'm also glad to see this project take off, and
will give it a spin soon.

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...](https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby8)

~~~
farresito
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).

~~~
oblio
With a bit of luck we'll have a gcc/egcs situation
([http://en.wikipedia.org/wiki/GNU_Compiler_Collection#History](http://en.wikipedia.org/wiki/GNU_Compiler_Collection#History)).

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...

------
famblycat
This thread is a good example of why the policy requiring that a post title
must match the article title doesn't always work.

The title is okay within the context of the site it's on, but it's completely
nonsensical on its own without that context.

~~~
davis
It used to have Neovim in the title... I'm not quite sure why a mod would
remove that.

------
yepguy
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?

~~~
fmoralesc
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.

[1]:
[https://github.com/fmoralesc/neovim/tree/providers](https://github.com/fmoralesc/neovim/tree/providers)

~~~
yepguy
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.

~~~
fmoralesc
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.

~~~
tarruda
> 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:

\- A way to spawn plugins through vimscript. This was fixed
[here]([https://github.com/tarruda/neovim/commit/acf17dbefef379ecb8e...](https://github.com/tarruda/neovim/commit/acf17dbefef379ecb8e8d95da0fb39d2d12acfc4))
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

~~~
fmoralesc
Of course. I meant the second point.

> \- A way to spawn plugins through vimscript. This was fixed
> [here]([https://github.com/tarruda/neovim/commit/acf17dbefef379ecb8e...](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.

------
pcmonk
I love how they're also contributing upstream to libuv. This is how you do an
open source, community-focused project.

~~~
tarruda
Also, There have been some contributions to msgpack-c:

\-
[https://github.com/msgpack/msgpack-c/pull/84](https://github.com/msgpack/msgpack-c/pull/84)

\-
[https://github.com/msgpack/msgpack-c/pull/109](https://github.com/msgpack/msgpack-c/pull/109)

\-
[https://github.com/msgpack/msgpack-c/pull/113](https://github.com/msgpack/msgpack-c/pull/113)

\-
[https://github.com/msgpack/msgpack-c/pull/118](https://github.com/msgpack/msgpack-c/pull/118)

------
lbradstreet
I am seriously glad that this is a thing. I donated after the original
bountysource, and seeing the momentum I may just donate again.

~~~
lbradstreet
Addendum: if it weren't for Tim Pope and his Vimscript mastery, I would
already be using emacs in Evil mode.

~~~
SeoxyS
+1. Tim Pope is the best. Neovim looks like it's shaping up to be the best,
too.

------
pestaa
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?

------
elwell
What's the equivalent of Newvim for Emacs? I had hopes for Deuce [0], but it
seems stagnant.

[0] - [https://github.com/hraberg/deuce](https://github.com/hraberg/deuce)
"Emacs under Clojure"

~~~
Avshalom
The GuileEmacs project probably.

~~~
Crito
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'.

------
banachtarski
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.

------
atdt
Kudos for keeping up the commitment to publish regular updates. The newsletter
gives the whole project a feeling of momentum and integrity.

------
RexRollman
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.

~~~
saidajigumi
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:

    
    
        brew install --HEAD https://raw.github.com/neovim/neovim/master/neovim.rb
    

From there, it's not going to be difficult to get a build from your own clone
up and running.

~~~
aeosynth
nvi is a reimplementation of vi, and is unrelated to neovim, a refactoring of
vim

~~~
RexRollman
Correct. By the great Keith Bostic!

------
varkson
If they can make Vim feel more modern and allow plugins to integrate better,
I'd be very very happy to move to this software.

------
cranium
:x == :wq

(I love conciseness.)

------
TheSoftwareGuy
I haven't been keeping up with neovim, but does it completely freak the fuck
out whenever I forget I have caps lock on the way that vim does?

~~~
TheSoftwareGuy
I seem to be getting downvoted, not really sure why.

