Bram, Given that your concern is to not present a situation to the user for which they have no remedy, it seems like providing information might be a possible remedy The more information the user has, the easier it might be to figure out how to get out of a possible sticky situation. You mentioned being able to list a list of names of timers might be a workable solution for you to get this patch in? Maybe being able to remove a timer by name? Would these additions suffice? Just curious. I'm not involved in the development of this plugin, but I would like to see it make it into vim. Maybe the timer can print its name as it starts to :messages so the user might have an idea as to what is currently happening if things hang.
On Wednesday, September 25, 2013 4:53:25 AM UTC-7, Bram Moolenaar wrote: > 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 -- [email protected] -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
