A few thoughts about this patch.
This is not asynchronous but these are timed commands. It should be
clear that the commands are executed in the "idle" loop, when Vim waits
for a character to be typed.
There might be two types: One that has high priority, and gets handled
even when the user has typed something. Another that has lower
priority, only gets handled when waiting for the user to type.
As someone already mentioned: If the command takes too much time, Vim
will get stuck. E.g. when it reads from a socket. It might be possible
to have this kind of work done in another thread, e.g. using Python.
The documentation is still missing. A lot of details need to be
explained there.
It must be possible to get a list of these commands, so that they can be
cancelled without having the id. This will then possibly break the
plugin that installed the command, so this gets messy quickly.
The code uses "long" to store msec, but you need 64 bits for that and
long can be 32 bits.
I don't see the need for 'ticktime'. The remaining time until the next
timeout can be computed. If it's smaller than 'updatetime' then wait
for that long.
--
hundred-and-one symptoms of being an internet addict:
170. You introduce your wife as "my_l...@home.wife" and refer to your
children as "forked processes."
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
--
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.
