> 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.
Its true that JS was designed in a weekend, but it is easily the most popular event driven language (where asynchronous programming is the norm). We chose setTimeout and setInterval as our model because they are the closest thing to what we wanted, are familiar to most devs, and can be reasonably implemented inside Vim. Also, they aren't one of the bad parts (http://oreilly.com/javascript/excerpts/javascript-good-parts/bad-parts.html) :P > > > 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. I recognize that things do go wrong, but I don't expect end users to do anything about it other than exit and change their ~/.vimrc. Fixing broken plugins and writing sane ones is squarely the responsibility of the plugin authors. Installing plugins (working or otherwise) is up to end users, and this has always been the case. I don't see why this patch should be treated any differently. If there is no way to diagnose or get out of infinite loops in general in Vim, what necessitates such a system exist here? Currently, any plugin can trivially create a busy loop that blocks forever. It is the job of the plugin authors to write code that doesn't do that. > 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. I disagree that a list of active timers is particularly helpful to end users for the following reasons: 1. Timers aren't like options or autocommands which are both static. They are mostly set at startup and never changed. autocommands exist on the human time scale. Timers come and go on the computer time scale. A well behaving plugin could realistically run a timer ever 30ms on the low end without ever bothering the user. 2. How will the user see the list of timers if Vim is blocked by a timer? Diagnosing troublesome timers is the only time a user would want this feature. 3. How will the user identify which timer is causing the slowdown? A timeout is only fired once; previous (troublesome) timeouts won't be in the list. Moreover, the list can be huge. 4. How does the end user even know that a timer is the problem in the first place? From his perspective, all he sees is that vim is unresponsive. 5. Canceling the wrong timer will lead to even more trouble (unlike autocommands which have no expectation of ever firing) and will make diagnosing the problem even harder. 6. The ability to cancel third party timers is dangerous. Imagine if different pages in a web browser could cancel timers they didn't set. Perhaps this feature would be OK at helping the end user diagnose slightly problematic intervals- ie, ones that block for a second or two, but it wouldn't do anything for infinite loops. I tend to think its easy enough to diagnose that problem without this feature. If a timers list is a hard requirement, I'm willing to write the code, but I don't think it adds much. > 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... Yeah, this is trouble and I'm open to suggestions. What does Vim currently offer for letting users get out of infinite loops? I would like to implement a solution, but I can't think of a satisfactory one that would take less than a month to write. I would guess the difficulty in implementing something like this is why it doesn't already exist (for unresponsive vim scripts). -Matt -- -- 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.
