On Monday, February 8, 2016 at 6:08:52 PM UTC-3, Bram Moolenaar wrote:
> Thanks for the feedback. I think it's time to sketch the upcoming work.
> It appears some thought that sockets was the end of it, that's not so.
Bram
I suggest to only focus on the job control feature, at least for now. The
reason is that job control as it currently exists in Neovim, is enough to cover
any asynchronicity requirements by plugins. Let me give some examples using
Neovim API.
```vimL
" Assume function named 's:JobCallback' exists in this script
let s:opts = {
\ 'on_stdout': 's:JobCallback',
\ 'on_stderr': 's:JobCallback',
\ 'on_exit': 's:JobCallback'
\ }
" First, the common use case which is to spawn a long running
program to process some data and return to Vim(in this case a syntax checking
command from gcc):
let job1 = jobstart(['gcc', '-c', '-gnats', 'x.adb'], s:opts)
" A socket connection to a daemon or remote server
let job2 = jobstart(['nc', '127.0.0.1', '1234'], s:opts)
" Download something with curl, saving to a file and notifying the user when
" complete(in neovim API, passing a string as first argument to `jobstart` will
" pass the program to the shell, just like `system()`)
let job3 = jobstart('curl -L -o - http://tarball.url.tgz > out.tgz', s:opts)
" Listen on a socket, waiting for rpc commands
let job4 = jobstart(['nc', '4567'], s:opts)
" Do something after 5 seconds
let job5 = jobstart('sleep 5', s:opts)
```
As you can see, by exposing a job control API that talks with processes through
stdin/stdout is enough to cover anything plugins might require. Even if you
want to spawn a program connected to a new pty, it would be possible with an
external process that forwards data to Vim!
The main reason neovim directly implements a rpc protocol in C is to support
the remote plugin host API (mainly to create language bindings without
modifying the core) and remote UIs. This would be impossible to do in pure
vimscript due to performance reasons.
But Vim does not have these requirements and IMO implementing the suggested
channel feature will only complicate maintenance when a simple job control
could do anything users require(let external processes worry about
system-specific differences since we only care about stdio!).
Another complication to keep in mind if implementing a json rpc: Vim buffers
can contain binary data, what would happen if one evals `getline(lnum)` in such
a buffer? The result would probably be invalid json. You'd have to walk through
every string returned by the json rpc engine in order to find and escape binary
data.
As I said in a previous thread, the old job control patch has almost everything
required to make this work, it just needs to be adapted to the current code and
for a callback-based API(the old implementation uses autocmd events). It will
also have to be adapted for windows, but there seem to be quite a few competent
windows developers that contribute to Vim(mattn) and could probably port this
without trouble.
Also, I hope you see benefit of following Neovim API: There are already few
popular plugins out there that use it with a good amount of success(neomake,
vim-go, vim-R...).
Just my two cents.
--
--
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.
