On Sunday, September 22, 2013 6:38:32 AM UTC-7, Bram Moolenaar wrote: > kans wrote: > > > > > Zyx, > > > > > > Thanks for the help. Intervals are no longer run if they error of any > > > sort (apart from a user interrupt which will likely happen > > > accidentally). I was also forced to change configure.in as the > > > monotonic timer on Linux needs to sometimes link against rt. I ran > > > autoconf and also dumped those changes into auto/configure file. They > > > run in both Linux and OsX. > > > > > > > > > Originally, I had hopped that this patch will be 100 lines tops, but > > > it is closer to 600. A good chunk of that is documentation and > > > touching the various make files. I think we have addressed all the > > > concerns (apart from changing the name). What would it take to get > > > this merged? > > > > I still have several problems with including this functionality. > > > > I would prefer this to be called timed events instead of async, since > > it's not really asynchronous. A timeout is for when you do something > > and it takes too long. What this is doing is setting a timer or a > > repeated timer. >
We can change the vocabulary if you like, but we wanted to follow a pattern that developers were already familiar with. We used the JavaScript names of setTimeout/setInterval/cancelTimeout. Sublime Text uses the same names. Emacs has a similar API. > > > There is no need for 'ticktime', one can compute the time until the next > > event and use that. It's also more accurate and has less overhead. > Matt is working on a fix for this. > > Like others I'm worried that some plugin creates a timer with a problem, > > and it keeps triggering over and over. The user must have a way to stop > > it. We'll change ctrl+c so that it stops future intervals as well as canceling the current timer. That should prevent Vim from hanging and let users save their work. We thought about something more complicated, such as showing a list of pending timers and letting the user cancel them one-by-one. Unfortunately, users can only guess at the problem timer(s). They'd need the equivalent of `top` to find the culprit(s). Worse, canceling the wrong one could easily break a well-behaved plugin. The only fix for the well-behaved plugin would be to restart Vim. Most other editors and frameworks have taken the stance that with great power comes great responsibility. If a timer causes problems, then it causes problems. Fault lies with the developer of the code that set the timer. Sublime Text, Emacs, JavaScript, Twisted Python (and more) work this way. > Also, there will be plugins that have interference with what some > > timer is doing, there needs to be a way to temporary disable them. > > It might be required to give the timers a name instead of an ID, so that > > specific timers can be disabled by name, instead of having to lookup > > their ID (how would one do that anyway?). > I think names for timers would cause more problems than they solve. Plugins could conflict with each other if they chose the same names for their timers. IDs assigned at runtime make conflicts impossible. Also, the pattern of returning an ID is not foreign to those who have used other setTimeout implementations. > > > What happens with timers when at a prompt, e.g. for ":s/pat/repl/gc"? > > Timers are run while the prompt is prompting. It's the responsibility of the plugin developer to not cause problems. Great power, great responsibility and all that. > > > > This is the kind of functionality where we may need to fix many bugs > > that are uncovered over time, like with the conceal feature. I am not > > going to include it before I'm convinced it works properly. > > I don't think there will be many issues, but I do see where you're coming from. You're responsible for maintaining Vim indefinitely, while people like Matt and myself can submit a patch and disappear. A conservative approach to new features is entirely understandable. If I were in your position, I'd probably behave similarly. But please be aware of the costs of *not* adding timers to Vim. Without them, whole categories of plugins are simply impossible: Indexing files in the background. Collaborative editing. Deep integration with debuggers and browsers. That's just what I can imagine in a few minutes. The entire Vim community could imagine (and build) so much more. There's a new generation of plugins waiting to be made. They just need timers. I hope you'll soften your stance on this patch. Sincerely, Geoff Greer http://geoff.greer.fm/ https://github.com/ggreer -- -- 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.
