Neovim

[Thiago de Arruda]

Some time ago I decided to fork vim to refactor code and implement new features, such as the job control patch.

Until yesterday, the plans for this fork existed only in my head, but now everything is documented in github: https://github.com/neovim/neovim . Anyone who likes the ideas is welcome to join :)

Best regards.

[Anton Bobrov]

> New plugin architecture

> Plugins are long-running programs/jobs (coprocesses) that communicate with vim through stdin/stdout using msgpack-rpc or json-rpc.

This is a terrible idea. Only a few plugins can get a benefit. It be a senseless overhead for others. Plugin developers only need an event loop with message queue.

[lith]

> > Plugins are long-running programs/jobs (coprocesses)
>

> This is a terrible idea. Only a few plugins can get a benefit.

From what I gather, this should enable writing plugins in any language/interpreter, which is a good thing.

I just hope NeoVim keeps full compatibility with existing vim plugins.

[Christian Brabandt]

I am not sure, I like the idea, I have seen too many forks (muttng,
cdrkit, ...) that ended up being abandoned, because the work behind it,
was underestimated.

What are your plans regarding the development of neovim and its
compatibility regarding Vim? Will you be following Vims development or
will Vim and neovim start diverging?

Best,
Christian
--
I think... I think it's in my basement... Let me go upstairs and check.
-- Escher

[LCD 47]

From a quick look at your project, it brings a number of welcome
simplifications, but there are also a few design decisions that seem
insufficiently thought out, which are (in my opinion) likely to haunt
you later.

> Migrate to a cmake-based build

Except CMake is a mess in its own right, that adds an otherwise
pointless dependency of the build process to C++. Probably not a huge
problem if you only care about gcc and Linux, but a gratuitous pain
nonetheless. What's wrong with just editing the existing Makefile? You
only have to do it once.

> Most of the platform-specific code will be removed and libuv will be
> used to handle system differences.

Except libuv is mainly intended for dealing with multiple _network_
connections. Sure, this might come in handy at some (much later) point,
but Vim is not I/O-bound. Saying that libuv will handle most of the
platform differences seems a little naive.

> Plugins are long-running programs/jobs (coprocesses) that communicate
> with vim through stdin/stdout using msgpack-rpc or json-rpc.

As somebody else put it, this is a terrible idea (but for different
reasons from the ones mentioned there). JSON-RPC over stdio, really?
Can you tell the difference between network concurrency and IPC
concurrency? I'd suggest taking a look at how, say, Postfix handles the
latter, then re-thinking all this approach.

> GUIs are separate programs, possibly written in different programming
> languages. Neovim will use its own stdin/stdout to receive input and
> send updates, again using json-rpc or msgpack-rpc.

Again, this seems backwards. The reason why Gvim can't do most of
the tricks Sublime Text does isn't too much integration with the GUI,
but not enough integration. You might want to spend some more time
pondering about this approach, too.

/lcd

[ZyX]

> Except libuv is mainly intended for dealing with multiple _network_
> connections. Sure, this might come in handy at some (much later) point,
> but Vim is not I/O-bound. Saying that libuv will handle most of the
> platform differences seems a little naive.

What?! `eix libuv` describes libuv as “A new platform layer for Node”. Project own README says “libuv is a multi-platform support library with a focus on asynchronous I/O.” Where do you see “network” here? Also feature list from this README tells about 12 features, and only two of them are about network.

[LCD 47]

On 22 February 2014, ZyX <zyx...@gmail.com> wrote:
> > Except libuv is mainly intended for dealing with multiple
> > _network_ connections. Sure, this might come in handy at some (much
> > later) point, but Vim is not I/O-bound. Saying that libuv will
> > handle most of the platform differences seems a little naive.
>

> What?! `eix libuv` describes libuv as ???A new platform layer for
> Node???. Project own README says ???libuv is a multi-platform support
> library with a focus on asynchronous I/O.??? Where do you see
> ???network??? here? Also feature list from this README tells about 12

> features, and only two of them are about network.

As far as I can tell, libuv provides exactly what you need to write
node-style network servers, and to this day those are still the most
spectacular of its applications. Can you also use it for something else
if you ignore the network features? Sure, since it basically brings
libev to Windows, and libev is also supposedly a better libevent. :)

Now, _should_ you use libuv as a cross-platform glue if all you care
about is (local) IPC, rather than heavily concurrent I/O? Well, maybe
not.

/lcd