If I am not mistaking, this patch includes "timers" string in has() list
two times.
In f_canceltimeout in a first if in a first if in a while cycle indentation
is wrong: 4 spaces go before tab. Later indentation is wrong for
+ free(tmp->sourcing_name);
line: spaces are used in place of tabs. Same for line
+ return (long)towait;
in call_timeouts().
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.
>
> -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.
