8 ms·

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 use

• jeremysmyth 13y ago
  An indirect attempt to troll for side-effects and hilarious race conditions perhaps?
• taeric 13y ago
  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.
• cma 13y ago
  One thing I run into a lot is that sometimes tab completion scanning ctags locks up the whole process for several seconds.
• seren 13y ago
  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. [1] https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ
  • njharman 13y ago
    GUI apps should be multi-threaded. But, process handling is OS task. Unix already provides facility for backgrounding of processes. :!long-process&
    • seren 13y ago
      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.
    • tarruda 13y ago
      I agree, but how do you get notified that 'long-process' finished running? Even if you poll using CursorHold-like hacks the user still needs to type something.
      • dllthomas 13y ago
        :!{ long-process ; notify-send "done" ; } &
        • tarruda 13y ago
          All that does is display a popup on the desktop, it does nothing to notify/callback to the vimscript code that started the process
          • dllthomas 13y ago
            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.
  • recuter 13y ago
    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.
    • seren 13y ago
      I am actually using vim-dispatch[1] that works fairly well. [1] https://github.com/tpope/vim-dispatch https://github.com/tpope/vim-dispatch
• chongli 13y ago
  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!
  • rjzzleep 13y ago
    ever tried youcompleteme? the redraw bothers me, but that's a different issue http://valloric.github.io/YouCompleteMe/ http://valloric.github.io/YouCompleteMe/
    • tarruda 13y ago
      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.