- syntax highlight
- decent automatic indenting
- semantic auto completion popup
- on the fly compile
- on the fly syntastic check(lint tool)
I think vim could be more responsive.
This slow response problem is only reason for trying other editor. Please make this real.
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.
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.
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.
See the issue tracker for examples of vimscript functions that can be added on top of the message queue: https://github.com/tarruda/vim/issues/2
Thanks for the correction; clearly I mischaracterized the use-case.
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.
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.
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
There is an ongoing discussion on the vim-dev mailing list regarding a proposed patch by Thiago Arruda . I have no opinion on the technical merit of the patch, but as a user, I would warmly welcome a move in that direction.
Even if you poll using CursorHold-like hacks the user still needs to type something.
Could be a temporary kludge at least until OP gets going.