Hmmm. So the benefit of this is offloading plugin processing onto a separate thread(s)? I guess I see the theoretical benefit of that, but I'm unsure of how useful this actually is...
Every time you launch a process from inside vim (like grepping multiple files, generating tags for a large project, etc) it totally freezes the user interface. You can not execute any long task in the background, which is really annoying. So having a multi threaded Vim is very much overdue.
There is an ongoing discussion on the vim-dev mailing list regarding a proposed patch by Thiago Arruda [1]. I have no opinion on the technical merit of the patch, but as a user, I would warmly welcome a move in that direction.
Yes. For many things that's what you want. I wasn't trying to say "this will meet all needs and make this entire discussion irrelevant"; I was posting lest anyone find it interesting/useful.
I think there are some use cases, like getting the syntax highlighting being processed by vim in another thread, that would help the responsiveness (or feeling of) if this was supported natively.
Wouldn't a simple fix be writing a little stub that acts like the Tee command line utility? It would immediately hand back to Vim and pipe onwards the command you sent it.
Could be a temporary kludge at least until OP gets going.
Ever had to sit and wait for vim to parse a gigantic file to get syntax highlighting correct? Just waiting for it to know the line numbers can take a while.
You haven't tried some of the heavier auto-complete plugins. As it stands right now, they have an annoying tendency to block the UI while you're typing! It's bothered me so much that I've even considered writing my own vi clone based entirely on an asynchronous message queue such as this!
The redraw issue is also related to vim not being thread-safe.
With this fork youcompleteme can probably do something like 'vim.defer("YcmTriggerSyntastic")' from a background thread to invoke syntastic and redraw the screen.
