[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.

[teacup50]

My only takeaway from the thread was that you approached the process of patch review begrudgingly, and seemed to assume that everyone should understand/appreciate your node-derived vocabulary and design.

Each iteration of the patch was provided with a whine about whether it was ready for inclusion yet ... when the reality is, that as the patch author, it's your job to make sure there aren't more bugs and the patch is ready for inclusion.

Every time someone found another issue was a red flag to any sane maintainer that your patch wasn't ready for inclusion. Every time you whined about having to iterate, you made it clear that you couldn't be trusted to have written something stable and maintainable.

If you can't deal with working on mature software, stick to startup code.

[Tyr42]

Multithreading and job control