Re: Neovim

On 21 February 2014, Thiago de Arruda <tpadilha84@gmail.com> wrote:
> 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 :)

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

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.