On Wed, Oct 16, 2013 at 06:49:09PM -0700, Ben Fritz wrote: > On Wednesday, October 16, 2013 8:40:23 PM UTC-5, Anton Bobrov wrote: > > > I like the idea for a threshold, but it would be a ton of work since it > > > > > would have to use threads and locking and vim isn't thread safe. This is > > > > > way more work than I am willing to put in even if it means this patch > > > > > doesn't get merged. > > > > > > > > > > -Matt > > > > > > > > Er, threads, locks? We only need to decide to kill or not to kill current > > > > active timer (if any). And this decision is based on start time solely. > > OK, so it sounds like maybe I like your idea: > > 1. If CTRL-C is pressed while a timer is running, check how long it has been > running. > 2. If it has been running longer than a threshold, cancel that timer for now > and forevermore. > > This way it wouldn't cancel anything if hit accidentally on a well-behaved > timer. > > 3. Also cancel all other timers? Maybe this isn't needed. But if a plugin has > multiple timers, you could hose that plugin worse by stopping only one of its > timers I bet. > > Perhaps a new feature could be added? Autocmds have groups, how about timer > groups? Then CTRL-C could cancel all timers in the same group. If a timer > doesn't have a group, it cancels all ungrouped timers. Then CTRL-C would end > only one plugin most of the time.
I think canceling only one timer is pretty enough. Vim should not keep self in ideal condition after emergencies. This is plugin author responsibility to take control of execution times and timer dependences. -- -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
