At this point it smells kind of Emacs/XEmacsish. Hope they can rally immense development effort.
At this point it smells kind of Emacs/XEmacsish. Hope they can rally immense development effort.
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
> 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.
This fork changes so much that its impossible that it will ever be accepted
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. :)
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.