On Oct 14, 2013 7:02 AM, "kans" <[email protected]> wrote: > > On Sunday, October 13, 2013 3:00:42 PM UTC-7, ZyX wrote: > > On Oct 14, 2013 1:00 AM, "ZyX" <[email protected]> wrote: > > > > > > > > > > > We also have :syntax on, filetype plugin on and so on. So I think it > > > > > > makes perfectly sense to be able to turn timers off globally using e.g. > > > > > > :timers off > > > > > > > > > > I still think that timers should have a string ID generated on plugin side. Since plugins will 99% of time reuse one ID for one task it allows collecting stats I described earlier. And with ID :timers off may then be reduced to > > > > > > s/allows collecting/allows collecting settimeout() stats and makes all (settimeout()+setinterval()) collected stats more readable/ > > > > > set ignoretimers=* > > > > > > > > > > (where 'ignoretimers' setting has 'wildignore'-like syntax and obvious purpose) if you think it is good to have some way to ignore timers: this way you can target specific plugin only. Like I will use after/ directory and :au!/:unmap if I see some too intrusive CursorHold event/mapping (though more likely I will remove the plugin) and definitely not 'eventignore' that will hurt all plugins. > > > > > > > > > > > > Note that all of :au!/:unmap/set eventignore/:filetype off/:syntax off/etc rely on good will of plugin authors: only laziness may prevent them from coding self-recovering in case user has disabled parts of the functionality. > > > > > > > > > > > > -- > > > > > -- > > > > > 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. > > There has been too much action in this thread to reply to everyone inline. > > Bram, > I happy to see there is still some hope for this patch getting merged. > > Ken, > Thanks for doing the work to clean up the patch. > > Dominique, > Thanks for the warnings. They should be gone now. > > glts, > 1. I believe your timer does the equivalent of this: > :call setinterval(0, "call canceltimeout(0)") > This caused the problem of double freeing the timer and has been fixed. Timers can now be created and canceled safely from within a timer. Canceling a timeout that is running does nothing. Canceling a running interval causes it to not be rescheduled. > 2. Concerning flickering, this is a bit of a problem for some use cases. We may need to write a couple of minor features to work around this (probably not as part of this patch). > 3. Check out https://github.com/Floobits/floobits-vim for a demo. It allows real time collaborative editing in Vim (and between emacs/sublime). You can ignore all the caveats since as of this +timers, neither +clientserver nor cursor hold is needed by the plugin. See https://news.floobits.com/2013/09/16/adding-realtime-collaboration-to-vim/for an explanation of how we got here and how painful the current solution is. > > Andre, > I agree with Ben and Zyx. If you don't want to deal with timers, don't install plugins that use them. There can be no expectation that any plugin will work if you disable its timers. If a plugin is more trouble than its worth, uninstall the plugin. Moreover, any interval can be canceled with ctrl-c and it won't be rescheduled (so this should never be an issue). > > At any rate, about 20 replies ago, I gave up trying to defend this position and implemented a way to disable all timers. They will eat up memory, but will never be called. Per the docs, "To globally disable all timers for debugging, set |ticktime| to -1." I still maintain using this for anything other than debugging is insane. > > Zyx, > I don't think giving timers names is necessarily a bad idea, but this patch is too big as is.
What about profiling? It is already not fine we need to be plugin developers to profile autocommands* and statusline, but timers are far more demanding in this case. If you do not add profiling/statistics right now it is fine, but if you do not add string IDs you will be unable to have nice output forever. IDs are needed to connect timers that seem different (e.g. in place of passing parameters in globals they pass parameters embedded in settimeout()/setinterval() string: the way I would prefer because I do not like using globals as parameters): those that you cannot connect based on cmd+SID pair. * Write just one :python/:ruby/... command in :au rhs and user no longer sees how much time did it take to run it (alternative is wrapping rhs into a function which will call :python/...). Plugin developers though may edit their own files to use python own profiling. Statusline is the same: e.g. powerline sets &stl to a "%!pyeval(smth)". If something is slow I need to guess which autocmd is it based on my knowledge of when they are launched. > -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.
