On Thursday, September 5, 2013 9:08:16 AM UTC-7, Ben Fritz wrote: > 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.
ctrl-c works (in this patch) because the OS converts it into a SIGINT which vim knows how to handle. >There might be two types: One that has high priority, and gets handled even when the user has typed something. Another that has lower priority, only gets handled when waiting for the user to type. As mattn pointed out, this won't work unless the internals of vim are threadsafe. > It must be possible to get a list of these commands, so that they can be > > cancelled without having the id. This wouldn't be much work, but to my knowledge, no other implementation has this ability. > I don't see the need for 'ticktime'. The remaining time until the next > > timeout can be computed. If it's smaller than 'updatetime' then wait > > for that long. This is true. ticktime is only useful for end users if they want to trade off efficiency for a better timer function. 50ms is probably a sane default that is good enough (and once again, no other implementation lets this bubble up to user land). Does anyone have any feedback on how this implemented; ie, putting this logic in mch_inchar vs. RealWaitForChar? Another issue is that vim makes other blocking calls that will block the timers. -- -- 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.
