Lcd wrote:
> [...]
> > > I don't really understand what problem do channels solve, or
> > > where is all this heading. Thus I'll refer mostly to jobs below,
> > > and I'll comment only on a few implementation details for channels.
> >
> > Jobs are processes, channels are a way to communicate. I don't see
> > how you can have jobs and not communicate with them in a useful way.
>
> I'm afraid I still don't get it. With jobs Vim can communicate
> with processes that aren't specifically aware they are talking to Vim.
> It can do that by opening pipes for the jobs' stdin and stdout. If
> it needs to give them "wheels" (that is, communicate with processes
> on another machine), this can be done with UCSPI. This is a solved
> problem, and the common solutions such as UCSPI can do things like
> connect over TLS (and actually get it right), and do fancy TCP window
> scaling and error recovery.
>
> On the other hand, there are daemons that do things like parse a
> source tree in background and can be queried about it over a socket.
> But these daemons have their own APIs, and are not specifically prepared
> to talk to Vim. Making Vim able to talk to them would require some kind
> of adapter, which might be a job started by Vim. But then the burden
> of handling protocols, TCP, and so on would be on the adapter. Vim
> could still talk to the adapter through pipes to the adapter's stdin
> and stdout. But the adapter would have to be written specifically for
> the particular daemon, and there's no way around that. If Vim is to
> talk directly to the daemon, without the adapter, then JSON or protocol
> buffers are either too much, or too little. I can't see how channels
> (as they are now) can fit into this picture. _shrug_
It seems you are missing that stdin/stdout IS the channel. On top of it
you can define the protocol: raw, NL-separated, JSON, etc.
So if that deamon speaks language X, then you connect with a raw channel
and let the Vim plugin decode language X. Hopefully you can do
something more clever (raw messages suffer from the problem that you
never know when the message ends).
It's the good old layering: lower layer about how to connect and
send/receive (socket, pipe, whatever), layer above that about the
contents (message separation and parsing). Even higher about what
request belongs to what response (what is currently only supported for
JSON, using sequence numbers).
> > > Why is it important for the job to be able to access a pty?
> >
> > Not important. We do need the I/O to go somewhere. Main problem is
> > input, if the job tries to read from the same terminal Vim will stop
> > working. But output could go to the same place. Might mess up the
> > display. So, normally "pty" means you have to setup the callbacks and
> > everything to make it work, while "open" would have the job happily
> > use some terminal. That would be required if the job has to prompt
> > for anything, or display progress.
> [...]
>
> I don't think a job's input can be allowed access to Vim's tty,
> ever.
Unless it's a filter. Or a job that needs to prompt the user. It's
tricky though, as soon as two processes read from the tty things go
haywire. But as you mention above, using existing commands that weren't
specifically made to be used by Vim this way, it may be the only way to
make it work. I expect that the thing we might need to support is a job
prompting for something only right at the start. E.g. to enter a
password. Imagine connecting to a server to access a database. Better
would be if the plugin can prompt the user before starting the job, but
that might not always work.
> There are two main cases here: programs that don't need any
> input, and are happy with command line options; and programs that need
> to read things from stdin. In the first case there's no problem to
> solve. It's the second case that's interesting, and there Vim could
> either use another callback for the job's stdin to feed it data as
> the job requests, or simply let it read from a file. The callback is
> problematic, because it can run into deadlocks with the callbacks for
> output (this is a well-known hard problem). Reading from a file is
> safe, but limits what the job can do.
Right. We'll probably need to see a practical example. We can have an
input handler, but asynchronously prompting the user for input, a
dialog that pops up, is a completely new concept. For now I think we
can omit it.
--
"You mean there really is an answer?"
"Yes! But you're not going to like it!"
"Oh do please tell us!"
"You're really not going to like it!"
"but we MUST know - tell us"
"Alright, the answer is...."
"yes..."
"... is ..."
"yes... come on!"
"is 42!"
(Douglas Adams - The Hitchhiker's Guide to the Galaxy)
/// 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/d/optout.
