Geoff Greer wrote:
> On Sunday, September 22, 2013 6:38:32 AM UTC-7, Bram Moolenaar wrote: > > 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. Java is the most used language these days and uses the Timer class. JavaScript wasn't designed properly, it has lots of confusing stuff, I would never use it as an example for proper design. Only for ideas. What is Emacs? :-) > > 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. Your attitude appears to be that you are making things work. Well, unfortunately things break once in a while. At some point in this design you have to think about what might go wrong and how to handle that properly. This is not something to be done as an afterthought. Plugins WILL interfere in ways you cannot imagine. It's naive to assume that they will all work properly. And the plugin writer cannot possibly overview all corner cases, no matter how clever he is. We must prepare for some plugin, or combination of plugins, to malfunction and provide the user with a way out. At least it must be possible for the user to find out what is causing problems, find the source of it and fix it or disable it. That is why we have the :verbose command, for example to find out who last set an option. For timers there must be at least a command that lists all active timers, when they trigger and where they were defined. Interrupting a timer with CTRL-C is hit-and-miss, by the time the key press gets through another timer may be active and you kill the wrong one. Having a prompt to ask the user what he wants to kill might help. But also interrupt the normal working sequence. And on Windows CTRL-C means copy... > > 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. You are exactly mentioning things that can go haywire: - Indexing in the background may hang, run at 100% CPU, change files that are being used, etc. - Collaborative editing will use network functions, which may hang. - Debugger integration is very complex, anything can go wrong. > 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. I won't include it before it has been done properly. -- Women are probably the main cause of free software starvation. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- -- 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.
