The author of NeoVim (Thiago de Arruda) tried to add support for multi-threaded plugins to Vim and has been stymied[1].

I'm not sure how to get a patch merged into Vim. Bram Moolenar is the only person with commit access, and he's not a fan of most changes beyond bug fixes. My co-founder and I tried to add setTimeout & setInterval to vimscript[2]. Even six weeks of full-time effort and bending over backwards wasn't enough. Eventually we were just ignored.

I've contributed to a lot of open source projects, and the Vim community has been the most difficult to work with. I've been writing C for almost two decades, and the Vim codebase is the worst C I've ever seen[3]. The project is definitely showing its age, and I'd love for something new to replace it.

1. https://groups.google.com/d/msg/vim_dev/65jjGqS1_VQ/fFiFrrIB...

2. https://groups.google.com/d/msg/vim_dev/-4pqDJfHCsM/LkYNCpZj...

3. If you value your sanity, do not read eval.c. It is over 25,000 lines and has over 400 ifdefs. The first ifdef checks for Amiga; the second checks for VMS: https://github.com/b4winckler/macvim/blob/master/src/eval.c

Your patches were broken. Now your answer is to fork? Sheesh.

> The project is definitely showing its age, and I'd love for something new to replace it.

Then start over. Refactoring it will be nigh impossible.

Vim was created on Amiga, so that's explainable

Re #3. Dude - you broke my browser with that link :(

As the author I would like to contribute changes back, search vim_dev mailing list for 'message loop' and 'job control' and you will find two patches I've sent that werent even commented by Bram.

This fork changes so much that its impossible that it will ever be accepted

I TOTALLY hear that.

Maybe an GCC/EGCS, eglibc/glibc, or (as nfm points out) Yarv/MRI scenario could work. First prove your mettle (will take donkey's years), then upstream can jump to your stable code base in one glorious commit.

Hope you can mention in the readme that upstreaming is not a goal... It might be hard to get the wording right but it would have made my first impression quite a bit less skeptical. :)

Maybe we can hope for an MRI/YARV scenario!

the author has posted at least two different patches to vim dev google group. I dont think Bram even commented in any of them. Many others did.

Bram shows no interest in these sorts of things. Frequently, devs post to the vim mailing with a month or two of work on some new feature with no comment from the BDFL.

So why don't all these people get together and fork?

I have only superficially browsed vim sources some months ago. Vim source code is literally disgusting. The number of platforms vim runs on is close to Avogadro's number. It supports 5 or sth languages for customisation. I always had in my mind to fork the thing and remove all those languages, and strip off the compatibility stuff so it will be a pure Unix program, but I never got to do it.

Also, the source repository contains binary (.a, .dll) files, which I did not inspect. I always search the web for an alternative editor when I somehow browse the vim source repository.

The stripped down version is called 'vi' :)

Well, I decided I'll play with acme* editor a little bit, if I can't get on well with it, I'll probably go that way.

* http://research.swtch.com/acme

Yes, I was surprised by this, and no mention of the project on vim.org ...