On 14/10/13 12:02, kans wrote:
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 outhttps://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.
Seehttps://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).
Why does everybody assume that any problem that can ever happen with a
timer plug-in will only happen in a plug-in that the user chooses to
install? Just
because the pre-shipped plug-ins have been checked against themselves it
does not mean they're bug-free. Welcome to the world of real-time systems.
The pre-built plug-ins may work when tested against themselves but a
plug-in I
install that is proven correct may cause the original pre-built plug-ins
to fail
because, being a real-time system, it was impossible to test the
pre-built plug-
ins against every future plug-in that was ever going to be written
(note: future
tense intended).
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.
This command is what I was looking for. It should be a standard, documented
command and not debug only.
I originally supposed that you could put such a command in a .vimrc to which
the standard response has been "but a plug-in can override it". Well,
analysing
my own behaviour, when things go wrong the first thing I want to do is
type ":"
to get a prompt and disable the problem. This means I:
1) Don't have to exit ViM, restart ViM, or re-read .vimrc or any
plug-ins/scripts.
2) Don't potentially lose any work I'm doing.
And for the person who quoted the syntax highlight case, the answer is yes,
when a syntax highlighting hangs my current session, I DO disable
highlighting
by typing ":" to get a command prompt and typing "syntax off". That
immediately
solves all problems, session is released and I can continue until the
next "quit".
In the same way, if half way through a session these timers cause me a
problem
I want instant out by ":timers off" at the prompt, not necessarily from
my .vimrc.
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
