David, Is it currently possible to introspect the file and line number of call site of sitetimeout? I think it would be enough to just error message that info when a timer is canceled.
-Matt On Tue, Sep 24, 2013 at 5:51 AM, David Fishburn <[email protected]>wrote: > > On Mon, Sep 23, 2013 at 8:53 PM, kans <[email protected]> wrote: > >> ... >> > > >> > 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. >> >> The new behavior cancels intervals if they error in any way. >> Additionally, upon further thought, there is no way around ctrl-C. That >> is, we have to use signals and ctrl-c (SIGINT) is the only convenient one. >> In the newest version, ctrl-c will cancel a given timeout/interval and all >> future calls. >> >> > FYI, I often use CTRL-C when Vim is taking too long (for example, my home > drive is N: and I am not connected to the network). I understand why we > want this, but I am just wondering how often people use CTRL-C within Vim. > > What I would _very_ much like to see is when CTRL-C is pressed, and there > are timed events, Vim would display the name of each timed event canceled. > I would also like to see future events differentiated. > > CTRL-C > Cancelled 21_DB_timedEvent > Future events cancelled > 21_DB_timedEvent > 34_SS_MyTimedEvent > 87_GG_hisTimedEvent > > That way, if I see a pattern that I am a canceling the same event over and > over, I can start vimgrepping my plugin / autoload directories to figure > out what plugin is installing that timed event. > > > >> > Also, there will be plugins that have interference with what some >> > >> > timer is doing, there needs to be a way to temporary disable them. >> >> The new solution is good enough from the user's perspective. If a rogue >> timer exists, the only possible action is to cancel it, save buffers, and >> restart vim after removing the offending plugin. No plugin is going to >> continue to work after its timers are canceled. >> > > If the CTRL-C shows the above information, we can at least identify > potential issue plugins. > > I think when we document this feature in the Vim Help files, it is > important to indicated every timed event should reference a GLOBAL variable > which will allow the plugin to disable the timed event. > > So, similar to how plugin developers follow the standard: > > if exists('g:loaded_myplugin') > finish > endif > let g:loaded_myplugin = 1 > > In our timed event sample (prominently displayed) in the help we could > have: > > let g:myplugin_allow_timedevent = 1 > > function! MyPlugin_timedEvent() > if g:myplugin_allow_timedevent == 0 > return > endif > > -- Do stuff here > endfunction > > This might help (especially) first time plugin writers of the timed event > feature to put in some safe guards ahead of time. > > > David > > -- > -- > 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 a topic in the > Google Groups "vim_dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/vim_dev/-4pqDJfHCsM/unsubscribe. > To unsubscribe from this group and all its topics, 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.
