I have been using the fork with timers for over a month now with a plugin that uses timers. It is pretty stable but I've seen it lock up and I have seen segfaults. I can reliably create a situation where cntrl+C doesn't escape and vim is completely frozen. We'll have to look at that once Bram is ready to give this patch another try, if he ever will. I'd say the segfaults are all problems with vim and not the patch, at least the ones I investigated. This patch allows code to be run at unexpected times and references to buffers can be gone by then. For example was a null pointer issue that kans mentioned in October on this mailing list and a fix for it has already gone into vim.
Any of the issues which timers have exposed, at least that I have seen so far, I think could have been a problem with a cursorhold event handler too. There is another segfault that shows up sometimes and I haven't tracked it down yet. It's intermittent and difficult to reproduce. The vim code base doesn't really lend itself to a thing like timers. I think Bram's instinct to put this off are right. However any of the problems this patch introduces would only be visible to people using the timer feature. I think a decent compromise might be to get the patch in, but have it turned off by default, and turned on by a compile flag. Maybe we can call it experimental-timers or something. I've started to work with Geoff and kans on their project (Floobits). There are enough vim users out there (myself among them) to warrant supporting a fork for as long as we're around. We'll try to keep it up to date with the latest changes. I don't think we're going to expend any more energy on this patch until Bram has the time to look at it. I am not sure that will ever happen at this point. On Friday, November 22, 2013 11:21:38 AM UTC-8, Charles Campbell wrote: > Bram Moolenaar wrote: > > > Michael Henry wrote: > > > > > >> I've been wondering about the use of CTRL-C regarding timers. > > >> There has been a lot of discussion on ways to regain control in > > >> the face of a runaway timer, which is of course an important > > >> consideration. I've been wondering, however, about any negative > > >> effects of accidental cancellation. If I understand correctly, when > > >> a user presses CTRL-C while a timer happens to be running, that > > >> timer will be canceled and not rescheduled. Can this happen > > >> accidentally when the user is pressing CTRL-C for other reasons > > >> (e.g., to abandon an ex-mode command he was typing)? Since > > >> timers might be running at arbitrary times, how can a user be > > >> sure it's safe to press CTRL-C without running the risk of canceling > > >> a timer by mistake? Should it require multiple CTRL-C presses in > > >> a row before aborting current and future timers, or is there some > > >> other way to make sure the user won't accidentally cancel timers > > >> that are operating properly? > > > The problem with timers is that they repeat. I would think a first > > > CTRL-C would "pause" a timer if it's clear that was the intention of > > > hitting CTRL-C. As suggested, that the timer has been running for more > > > than a certain time would work. Anything that's stuck must quit when > > > CTRL-C is pressed. That's what it's for. > > > > > > But if the timer runs for a short time, but very often, it may still > > > cause the user to hit CTRL-C to stop it. Perhaps we can detect that the > > > user types CTRL-C twice in a row, then we know we need to cancel more > > > than just the current operation. If there are multiple things that > > > could be interrupted, a "what do you want to interrupt?" dialog could be > > > used (although that's not really user friendly). > > > > > > I would prefer to have CTRL-C pause the timer instead of completely > > > killing it. That gives a way to recover. E.g. if the timer uses a > > > socket that is temporarily unavailable. Would require a "resume timer" > > > command. > > > > > Would a closely spaced pair of ctrl-c's be detectable and useful in > > cancelling timers? (ie. one ctrl-c would not suffice, but a doubly-hit > > ctrl-c would). > > > > Regards, > > C Campbell -- -- 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.
