On Sep 26, 2013 3:30 AM, "kans" <[email protected]> wrote: > > > 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.
This is only true for python. Infinite loop can be canceled by CTRL-C if it is written in VimL and author is not intercepting interrupts just to make the loop unkillable. > > 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. Plugin should not be expected to be well behaving. > 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. He will use CTRL-C. Then see the list. > 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. Use string identifiers as suggested. This is how you can collect stats I said to be fine to see in previous message. > 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. If he is not already experienced he will be asked to launch command that shows stats when he comes with his problem to stackoverflow. > 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. You can undefine plugin functions. If one wants to make problems for the plugin he already has enough capabilities to do this. > 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. Commands, functions, autocommands, mappings - they all can be undefined/altered by a third party timers. This is less dangerous then expecting deferred function to take 30 ms when launched. > > 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). I am wondering why you are acting here like if CTRL-C does not work. From my experience this always helps against problematic VimL scripts (but not python plugins; likely ruby/lua/perl/... have the same property). It makes sense though to collect such stats only on request. Currently there is only one thing that can add problems without easy method (I mean profiling) to determine that it is it: statusline that does not use VimL functions. AFAIR you execute Ex commands in timer. If I am right how one is going to debug if problematic timer is running only :ruby $command_t.update_index (an example, I do not claim Command-T has such method) (except for the usual disabling of the plugins)? Also are timers run shown when you :set verbose to some high enough value? It would be fine if such stats collection functions are written in a way that can be later attached to autocommands: if e.g. InsertCharPre event fires only some python/... script this will also come unprofilable and only seen in verbose mode. Note that stats provide only information for the user. Developer in such cases will use in-lang profiling capabilities. > -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. -- -- 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.
