[CJefferson]

To be fair to the authors of neovim, there were patches they wrote and submitted to vim, which added exciting new features I would like, which were rejected.

People who basically want him to never change (and that is fine) can be happy with mainline. There are others who would like to see some significant updates, particularly allowing better threading support.

[andrewflnr]

> To be fair to the authors of neovim...

Sounds to me like you need to go farther. "We should improve what we have" totally fails as a criticism when written by the same guy who won't let the product in question be improved.

If there's good reasons not to admit patches, fine, let's hear them, but don't give me this glib "we should improve what we have" crap. I can hardly believe that's basically his only answer.

[shmageggy]

What were the features they submitted? Stuff that's mentioned on the github page or something else?

[btipling]

At Floobits we tried to submit set_timeout/async stuff, and couldn't get anywhere with Bram. Months of work wasted.

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

[teacup50]

Your patches were broken. People spent plenty of time trying to help you fix them.

Your response is to tell the Internet that Vim is wrong for not accepting broken patches?

[ggreer]

All of the crashes we encountered can be reproduced with stock Vim, using a combination of updatetime and CursorHold/CursorHoldi autocommands. These are bugs in Vim, but they're rarely hit because few plugins (ab)use Vim in this way.

[Jasber]

Did you read the same thread I did? Floobits addressed all the issues.

It came down to a fundamental design decision—and after months of hard work, they got a non-answer.

[ampersandy]

Bram's last post was 10/21/13, and a month later Bjorn confirmed in his fork that he could reliably freeze VIM and had segfaults that he had yet to fix. The final word seemed to be:

"There are enough vim users out there (myself among them) to warrant supporting a fork for as long as we're around. We'll try to keep it up to date with the latest changes."

I don't think anyone should expect Bram to chase them down for updates to the patch. Reading through the discussion, it seems clear to me that while good-natured, the feature was not ready to be merged into VIM.

[Jasber]

I agree segfaults are a problem if caused by the patch, but it looks like those may have been bugs in VIM itself.

I think the bigger problem was just that nobody could agree on the cancel/freezing timer issue.

To me that's a design decision a maintainer has to make, not someone submitting a patch.

[btipling]

We actually continued to work on the fork until it was clear Bram wouldn't be responsive to any more changes. Once it became clear he wouldn't accept the patch we stopped wasting more time as we are trying to create a viable business. We weren't going to sink our startup for the sake of vim, as much as I love the editor. We spent a long time, it was a frustrating experience, so yes we tell the internet when it comes up. Any of the freezes we found we would have loved to patch back into vim had this gone differently, and it would have been a lot of work.

[Tyr42]

Multithreading and job control

[cseelus]

Yeah, threading comes to mind, as well as decend indentation of wrapped lines. Both rejected.