On Sep 11, 2013 1:54 AM, "kans" <mkania...@gmail.com> wrote: > > On Thursday, September 5, 2013 10:53:39 AM UTC-7, kans wrote: > > 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. > > I've attached our latest patch. We moved some of the logic down to the level of poll/select (RealWaitForChar) using MAY_LOOP which is similar to what the scheme bindings do; it is cleaner and works better. We also changed the eval call to use do_cmdline_cmd which is far more convenient. Now, the timeouts don't have to be user defined functions. Also, all timeouts can now be disabled by setting 'ticktime' to -1. We discussed disabling intervals that fail, but we ultimately decided that the onus should be on programmers to make sane plugins and canceling intervals is unexpected behavior. Finally, the new features are now documented. Please let us know what you think.
Why do you keep calling it async? Also other issues: 1. async.c does not follow coding style: 1.1. each 8 indentation spaces should be replaced with a tab 1.2. each opening figure brace should be present on its own line 1.3. no (void) in function declaration 2. async.h should be split into globals.h and proto/async.pro. async.h itself is to be removed. 3. Never use gettimeofday for intervals. There are special monotonic clocks in all operating system, for linux it is clock_gettime(CLOCK_MONOTONIC_RAW). What you use is subject for ntp daemon/ntpclient updates. 4. There is a proper way to disable a setting. Putting the whole setting into an #ifdef is not the one. 5. Documentation of 'ticktime' lacks references to +smth. I repeat, do not call smth "async". Not until you will make it execute asynchronously. 6. I do not see patch for the file with a list of features. > -- > -- > 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. -- -- 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.
