On 8 February 2016, Thiago Arruda <[email protected]> wrote:
> > NeoVim is free to follow. It appears NeoVim's ideas about jobs and
> > channels are quite different. And it seems to be quite complicated.
[...]
> But in the context of an editor like Vim, the main use case for
> background jobs is to allow implementation of asynchronous plugins
> that parse/send data to the process(like the coprocess feature in
> bash/zsh), so it would make more sense to simply have `job_start`
> receive callbacks that are invoked when the process sends data, and
> add a function to send data to the job's object(IMO this is simpler
> than going through the additional step of setting up a channel)
[...]
+1 for these particular points. IMO the main use case for jobs
won't be Vim spawning a daemon and talking to it occasionally, but
rather Vim running a lengthy process in background, reading results, and
updating them on the fly. And callbacks for the job's stdin, stdout,
and stderr is a nice way to handle that.
The alternative to callbacks would be polling the job's output, and
that would be less than great. This is how the existing async plugins
(vimproc etc.) work, and that's a major pain point because there is no
good way to do polling in Vim.
Incidentally, it's also important to be able to keep the job's
stderr and stdout separate from one another. Not being able to do that
is a deficiency of system().
Unrelated: the default for killonexit for job_start() should be
1. I think there's a tiny minority of situations when Vim 0 would be
desirable. In the vast majority of cases background processes that
would survive Vim would be runaway processes that would just consume
resources.
/lcd
--
--
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/d/optout.
