On Thursday, September 5, 2013 8:44:15 AM UTC-5, Bjorn Tipling wrote: > > As someone already mentioned: If the command takes too much time, Vim > > will get stuck. E.g. when it reads from a socket. It might be possible > > to have this kind of work done in another thread, e.g. using Python. > > > Hey check this out: > > au CursorHold * call BlockForever() > > > " Blocks forever > function! BlockForever() > let c = 1 > while c >= 0 > let c += 1 > endwhile > endfunction > > You can already do this blocking, I've already experienced it with plugins > I've removed. I ask again why setTimeout should be treated differently than > CursorHold? You can cntrl-c out of CursorHold, but just then make that a > requirement for settimeout. >
Exactly. I think as long as you can interrupt the timer with a keystroke it should be fine. But since you call your timer in between waiting for a keystroke, won't that prevent CTRL-C from interrupting it? Maybe it won't...I haven't tried it. I don't think we have any unique constraints, I just think that (a) it should be mentioned in the help that the timer blocks user input while processing, it's not a true asynchronous process and (b) it is required that CTRL-C or similar can interrupt the timer like it can already for autocmds, etc. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
