Kazunobu Kuriyama wrote：
> Looks you are trying to simplify the issue too much.
>
> Your argument looks good for utilities such as grep, tail, cut and so on.
>
> However, Vim (or any other programs having UI which is driven by events) is
> different from them in that, while Vim is made busy to handle a deluge of
> input from an external program, it also has to ask the terminal or the GUI to
> update its contents simultaneously (in appearance, at least).
>
>
> Actually, the event loop cannot handle the both tasks simultaneously; it
> tries to do only one thing when select() or poll() is called, and it can
> execute a thing only after it makes sure another is staying idle at that
> time. IOW, an illusion that both external input handling and UI update
> appear to happen simultaneously is made possible only if both of them can
> stay idle alternatively.
>
>
> The GUI will be locked if it is not given a chance to run the event loop for
> its own sake.
>
>
> The third element UI makes your issue very tough, and that issue itself is
> inherently difficult; while the user is asking an external program to do its
> job asynchronously, he is also asking Vim to show the result as if they were
> working synchronously, using the UI which inherently works asynchronously. A
> awful set of simultaneous equations.
>
>
> That said, I never mean that any effort done here so far doesn't make sense.
> Actually, I already enjoy the fruit; as far as the examples skywind3000
> raised (except the one after 8.0.105) are concerned, the issue appears to be
> fixed for me.
>
>
> --
>
> --
>
> 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+u...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
Thanks for your reply,
You mean I spoke too much on the same topic ?
I think I know what a event-loop is, I wrote a lot of gui programs
with win32 and qt before.
This is not as complex as you said before, for example: EditPlus/GEdit can get
background jobs working correctly.
Last week when I was trying to get grep working with vim's job system. It just
worked, but wasn't so perfect.
Vim got freezed when grep trying to output a lot of messages in a short time
(this can be reproduced by running grep in your document root with a very
simple word). Channel callback consumes too much time.
I was curious that what will happen if I run the same grep command in other
editors like EditPlus or GEdit.
Switching to EditPlus and setting grep as an "User Tool" in EditPlus, I found
EditPlus never got freezed, it just slow down the speed of grep.
So I am trying to solve it by introducing a flow control like mechanism:
invoking ch_read(..., {"timeout":0}) fixed times in a timer. If vim doesn't
read as faster as the child process, child should block when system pipe is
full.
Child process could be slow down and Vim can run as smooth as usual.
After digging a lot in the channel.txt, I suppose a channel (without callbacks)
can work as a traditional non-blocking socket. Just like other runtime
libraries of many programming language.
It's much simply then the callback implementation. We don't even need to put
these fds into the fd-set of select/poll if a channel is created without
callbacks.
Everything is fine if the channel (without callbacks) can just work like a
nonblocking socket. (that is it has a nonblocking "read" function and can
returns some messages or tells me EAGAIN/EWOULDBLOCK).
Thanks to Bram, we have job/channel system now and sure it is awesome. And I am
thinking these asychronous apis will be used in the next decade or even longer.
Great plugins will be born under the advantage of them.
If we can get grep to work perfectly with vim today. We can expect many
gorgeous plugins tomorrow.
--
--
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/d/optout.
