> 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.
Hey check this out:
au CursorHold * call BlockForever()
" Blocks forever
function! BlockForever()
let c = 1
while c >= 0
let c += 1
endwhile
endfunction
You can already do this blocking, I've already experienced it with plugins I've
removed. I ask again why setTimeout should be treated differently than
CursorHold? You can cntrl-c out of CursorHold, but just then make that a
requirement for settimeout.
> 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.
As was already pointed out, this is what asynchronous execution looks like in
JavaScript. JavaScript in the browser and elsewhere has only one thread of
execution, and the behavior of setTimeout in these contexts is similar to this
patch. Whatever you want to call this patch, it is very powerful, and vim is
missing it. Try implementing a clock for the status line in current vim. It
updates only after a keystroke. With this patch, you can have a real clock,
that shows you the actual time! Not the time you last pressed a key.
Try this in a Chrome console:
function blockForever() {
var c = 1;
while (c > 0) {
c++;
}
}
window.setTimeout(blockForever, 1000);
You get the same behavior that you would from this patch, the same behavior
that CursorHold gives you.
I agree there needs to be documentation on how to use this. I've built vim with
this patch and was able to get one plugin that uses setinterval to work, but
was not able to get my own attempt to work after a quick attempt.
On Thursday, September 5, 2013 4:26:41 AM UTC-7, Bram Moolenaar wrote:
> 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_la.wife" and refer to your
>
> children as "forked processes."
>
>
>
> /// Bram Moolenaar -- Bra....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.
