1 month is not a long of time. Specially when you are waiting for core developers of a busy project. Besides that this month had several holidays. Maybe you just need some faith.
Depending on faith will probably lead to bad decisions, a rational appraisal of available evidence and some critical thinking will probably be more useful. And let me present some evidence that may destroy any remnant of that faith you have:
That's our async/timers patch, we pretty much gave up for now because debugging vim was a nightmare. Right now something is stomping over regexp objects in memory. We have no idea where. We've found unsafe pointer use, etc. Vim code is pretty much all globals, 25k lines and 400+ ifdefs for at least one file, some crazy file encoding, pre C89 C that still compiles on an amiga, mixed tabs and spaces. The vim code base is pretty much the worst code I've ever seen and Bram doesn't seem to really grok our patch. He's also been demanding with his requests that we feel are over the top. That's fine, that's his choice. We're focusing on other plugins right now, we put in many months of work into vim. It kinda works as long as you don't use leader keys.
Thanks for the link to an interesting discussion. While I can't speak to the quality (or otherwise) of the vim code, I wouldn't characterize that conversation as "demanding" or "over the top". Even the most recent patch is reported to cause hangs when doing something as simple as pressing the leader key. You can't rationally expect a maintainer of mature software to sign up for that. I doubt Debian or other downstreams would be happy to hear that the vim maintainer had signed up for that.
If the fork is maintained for a year or so, fixing problems with the timer code and feeding patches for actual vim bugs back upstream, and adding tests for all of that, at the end of that time this patch will be quite different. It might even be in a form the vim maintainer can merge in good conscience. As an added benefit, by that time some compelling plugins that take advantage of these timers might be written. As it stands now, the use-case for this patch is rather hypothetical. Indeed, if after a year there aren't a few plugins around that make good use of this functionality, it calls this entire effort into question.
> As it stands now, the use-case for this patch is rather hypothetical.
I agreed with you up to this point. As it stands, many utility plugins (like CtrlP and Syntastic) and bundles/ftplugins (vim-python, my own vim-pantondoc) would be improved by this functionality. It is obviously wanted/needed by the Floobits plugin, which motivated the creation of the patches proposed last year. So, I don't think the effort can be reasonably put into question, as you say, even today. People do need async in vim, and also people would want upstream to handle this ASAP, by deciding on some strategy to provide it.
This said, this new message queue API seems cleaner than Floobits', but it seems to cater to python interop only, which is a mayor downside, since many vim plugin users opt out on python or simply lack python support.
> If the fork is maintained for a year or so, fixing problems with the timer code and feeding patches for actual vim bugs back upstream, and adding tests for all of that, at the end of that time this patch will be quite different.
There are few problems with the timer code. Vim's code is a monster. As you yourself admit, you don't know the vim code, so how could you possibly judge how demanding the requests are or make any of these other claims.
> The use case is hypothetical
We're building a business on real time editor plugins that isn't hypothetical at all.
I have to agree with the peer poster. That thread only shows a level of attention to detail that is required when producing software that's intended to behave reliably.
Bear in mind that drive-by patches have to be maintained forever by the person who is reviewing them. It's often easier to not respond at all, or to implement the work yourself, than to explain all the nuances around correctness and maintainability that may not be obvious to a new contributor.
Some projects are more accepting of patches, but they also then have to accept the of patches to fix those patches, and patches to fix the patches that fixed the patches.
Other projects try to get things right the first time so that there isn't a second time.
Perhaps with enough pressure from the community there's a chance this will happen?
Meanwhile I will keep maintaining the fork up-to-date with upstream, so plugins can make use of the patch through a simple 'if has("messagequeue")' conditional
