Re: Channel & job design

Christian Brabandt wrote: > > > Can we make it work with vim commands? What comes to mind would be to > > > have syntax highlighting work asynchronously, so Vim would stay > > > responsive for languages that have known to be slow syntax highlighting. > > > > Hmm, that's something completely

Re: Channel & job design

On Fr, 12 Feb 2016, Bram Moolenaar wrote: > Christian Brabandt wrote: > > > Can we make it work with vim commands? What comes to mind would be to > > have syntax highlighting work asynchronously, so Vim would stay > > responsive for languages that have known to be slow syntax highlighting. >

Re: Channel & job design

Charles Campbell wrote: > Bram Moolenaar wrote: >> Lcd wrote: >> >> There are also UNIX domain sockets (a.k.a. named pipes), which you get >> essentially for free once you have the code for INET sockets. They are >> as efficient as (unnamed) pipes. The code is already there, but it's >> mutually

Re: Channel & job design

Bram Moolenaar wrote: > Lcd wrote: > > There are also UNIX domain sockets (a.k.a. named pipes), which you get > essentially for free once you have the code for INET sockets. They are > as efficient as (unnamed) pipes. The code is already there, but it's > mutually exclusive with INET sockets. I

Re: Channel & job design

On 21:09 Sun 14 Feb , Bram Moolenaar wrote: > > Marcin Szamotulski wrote: > > > > > > > That's a really great feature. I am trying to implemented a gulp > > > > > > plugin > > > > > > (gulp is a node package used to build web apps) based on channels > > > > > > and > > > > > > there are

Re: Channel & job design

On Friday, February 19, 2016 at 6:58:48 AM UTC+9, Bram Moolenaar wrote: > I don't quite get it. Looking at the code, this ch_readraw() doesn't > specify a callback for the one read, it specifies a new callback for the > channel. That's not what the user expects. Better do something like: > >

Re: Channel & job design

Yasuhiro Matsumoto wrote: > --=_Part_725_18982456.1455794219476 > Content-Type: text/plain; charset=UTF-8 > > On Thursday, February 18, 2016 at 11:22:37 AM UTC+9, mattn wrote: > > On Monday, February 15, 2016 at 5:09:17 AM UTC+9, Bram Moolenaar wrote: > > > Marcin Szamotulski wrote: > > >

Re: Channel & job design

On Thursday, February 18, 2016 at 11:22:37 AM UTC+9, mattn wrote: > On Monday, February 15, 2016 at 5:09:17 AM UTC+9, Bram Moolenaar wrote: > > Marcin Szamotulski wrote: > > > > > > > > > That's a really great feature. I am trying to implemented a gulp > > > > > > > plugin > > > > > > > (gulp

Re: Channel & job design

On Monday, February 15, 2016 at 5:09:17 AM UTC+9, Bram Moolenaar wrote: > Marcin Szamotulski wrote: > > > > > > > That's a really great feature. I am trying to implemented a gulp > > > > > > plugin > > > > > > (gulp is a node package used to build web apps) based on channels > > > > > > and >

Re: Channel & job design

赵启明赵 wrote: > I've tried these simple code for job control > > let job = job_start('echo abc', {'waittime': 1}) > let channel = job_getchannel(job) > let output = ch_readraw(channel) > call setline(1, output) > > And I got NULL character inserted at the end of first line, I thought > is should

Re: Channel & job design

I've tried these simple code for job control let job = job_start('echo abc', {'waittime': 1}) let channel = job_getchannel(job) let output = ch_readraw(channel) call setline(1, output) And I got NULL character inserted at the end of first line, I thought is should be trimmed by vim. -- --

Re: Channel & job design

Marcin Szamotulski wrote: > > > > > That's a really great feature. I am trying to implemented a gulp > > > > > plugin > > > > > (gulp is a node package used to build web apps) based on channels and > > > > > there are two things that I has a problem with: > > > > > > > > Thanks for the

Re: Channel & job design

On 23:58 Sat 13 Feb , Bram Moolenaar wrote: > > Marcin Szamotulski wrote: > > > > > That's a really great feature. I am trying to implemented a gulp plugin > > > > (gulp is a node package used to build web apps) based on channels and > > > > there are two things that I has a problem with: >

Re: Channel & job design

Hello Bram! That's a really great feature. I am trying to implemented a gulp plugin (gulp is a node package used to build web apps) based on channels and there are two things that I has a problem with: 1) when I use `job_start()` to start a server in the background and immediately after I call

Re: Channel & job design

Marcin Szamotulski wrote: > That's a really great feature. I am trying to implemented a gulp plugin > (gulp is a node package used to build web apps) based on channels and > there are two things that I has a problem with: Thanks for the feedback. Keep in mind that the feature is still being

Re: Channel & job design

Marcin Szamotulski wrote: > > > That's a really great feature. I am trying to implemented a gulp plugin > > > (gulp is a node package used to build web apps) based on channels and > > > there are two things that I has a problem with: > > > > Thanks for the feedback. Keep in mind that the

Re: Channel & job design

Hi Bram! On Mo, 08 Feb 2016, Bram Moolenaar wrote: > That's plenty already, but we may need a few more. Can we make it work with vim commands? What comes to mind would be to have syntax highlighting work asynchronously, so Vim would stay responsive for languages that have known to be slow

Re: Channel & job design

Marius Gedminas wrote: > On Tue, Feb 09, 2016 at 10:24:55PM +0200, LCD 47 wrote: > > > - A socket (what ch_open() currently does) > > > - A pipe (only possible with an associated job) connected to > > > stdin/stdout/stderr. > > > > There are also UNIX domain sockets (a.k.a. named pipes),

Re: Channel & job design

On 10 February 2016, Bram Moolenaar wrote: > > Marius Gedminas wrote: > > > On Tue, Feb 09, 2016 at 10:24:55PM +0200, LCD 47 wrote: > > > > - A socket (what ch_open() currently does) > > > > - A pipe (only possible with an associated job) connected to > > > >

Re: Channel & job design

Thiago Arruda wrote: [picking out individual points to avoid trying to discuss everything at the same time] > The reason I said we would not follow Vim is because I honestly felt > that the job proposal for Vim was a regression when compared to what > we have in Neovim(and I know many plugin

Re: Channel & job design

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

Re: Channel & job design

Hi Bram On Wednesday, February 10, 2016 at 1:14:21 PM UTC-3, Bram Moolenaar wrote: > I wonder if you read my proposal wrong, or perhaps I didn't explain > something properly. I read your response, and can only say that it's > all covered in what I proposed. > > I think it may be caused by the

Re: Channel & job design

On 10 February 2016, Bram Moolenaar wrote: > > Lcd wrote: > [...] > > 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 > >

Re: Channel & job design

Thiago Arruda wrote: > On Wednesday, February 10, 2016 at 1:14:21 PM UTC-3, Bram Moolenaar wrote: > > I wonder if you read my proposal wrong, or perhaps I didn't explain > > something properly. I read your response, and can only say that it's > > all covered in what I proposed. > > > > I think

Re: Channel & job design

On 9 February 2016, Bram Moolenaar wrote: > > 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. > >

Re: Channel & job design

On 10 February 2016, Marius Gedminas wrote: > On Tue, Feb 09, 2016 at 10:24:55PM +0200, LCD 47 wrote: > > > - A socket (what ch_open() currently does) > > > - A pipe (only possible with an associated job) connected to > > > stdin/stdout/stderr. > > > > There are also UNIX

Re: Channel & job design

On 10 February 2016, LCD 47 wrote: > On 9 February 2016, Bram Moolenaar wrote: [...] > > We can support that later. As far as I know the main difference is > > how you connect, after that it's basically the same. Since we are > > using the netbeans code it

Re: Channel & job design

On 8 February 2016, 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. > > > For jobs the most useful are probably: > - A deamon, serving several Vim

Re: Channel & job design

On 9 February 2016, LCD 47 wrote: [...] > Starting a (presumably long-lived) server from Vim on the other hand > is a very different animal. A server might print things like error > messages before it goes to background. After that it isn't supposed > to print anything or

Re: Channel & job design

On 09-Feb-16, Christian Brabandt wrote: > Thanks for the constructive feedback. I appreciate it, that you as the > Neovim creator give feedback here. It's also appreciated, that certain > bugs, which have been found when developing Neovim have at least found > their way back to Vim itself

Re: Channel & job design

On 09-Feb-16, Olaf Dabrunz wrote: > Ah right, you already use this in 7.4.1274. > > To correct myself: kill the negative of the PID of the session leader, > this sends the signal to all processes in its process group (!), see > kill(2): > > mch_stop_job(): > > sig = atoi((char *)how); >

Re: Channel & job design

On 09-Feb-16, Olaf Dabrunz wrote: > On 09-Feb-16, Olaf Dabrunz wrote: > > Ah right, you already use this in 7.4.1274. > > > > To correct myself: kill the negative of the PID of the session leader, > > this sends the signal to all processes in its process group (!), see > > kill(2): > > > >

Re: Channel & job design

On 09-Feb-16, Olaf Dabrunz wrote: > On 09-Feb-16, Olaf Dabrunz wrote: > > On 09-Feb-16, Olaf Dabrunz wrote: > > > Ah right, you already use this in 7.4.1274. > > > > > > To correct myself: kill the negative of the PID of the session leader, > > > this sends the signal to all processes in its

Re: Channel & job design

Olaf Dabrunz wrote: > > > On 08-Feb-16, Bram Moolenaar wrote: > > > > Some parts that we still need that require some thougths: > > > > > > > > - Communicating over a socket requires knowing the port number. For a > > > > deamon this would be a known number. For a server started by Vim it's

Re: Channel & job design

On 09-Feb-16, Bram Moolenaar wrote: > > Olaf Dabrunz wrote: > > > > > On 08-Feb-16, Bram Moolenaar wrote: > > > > > Some parts that we still need that require some thougths: > > > > > > > > > > - Communicating over a socket requires knowing the port number. For a > > > > > deamon this would

Re: Channel & job design

On Tuesday, February 9, 2016 at 4:36:48 PM UTC-3, Christian Brabandt wrote: > Thanks for the constructive feedback. I appreciate it, that you as the > Neovim creator give feedback here. Hi Christian, I also appreciate you taking notice. > It's also appreciated, that certain > bugs, which have

Re: Channel & job design

Lcd wrote: > On 8 February 2016, 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. > > > > > > For jobs the most useful are probably: > > - A

Re: Channel & job design

Hi Thiago! On Mo, 08 Feb 2016, Thiago Arruda wrote: > 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

Re: Channel & job design

On Tue, Feb 09, 2016 at 10:24:55PM +0200, LCD 47 wrote: > > - A socket (what ch_open() currently does) > > - A pipe (only possible with an associated job) connected to > > stdin/stdout/stderr. > > There are also UNIX domain sockets (a.k.a. named pipes), which you > get essentially for free

Re: Channel & job design

On 09-Feb-16, Bram Moolenaar wrote: > > Olaf Dabrunz wrote: > > > On 08-Feb-16, Bram Moolenaar wrote: > > > Some parts that we still need that require some thougths: > > > > > > - Communicating over a socket requires knowing the port number. For a > > > deamon this would be a known number.

Re: Channel & job design

On 2016-02-08, Bram Moolenaar wrote: > One problem that I haven't figured out yet: When starting a job using a > shell, we get the PID of the shell. So we can kill the shell, but not > the process that it started. > E.g. "/bin/sh python demoserver.py there". A shell is also > useful for

Re: Channel & job design

I have read your thoughts about msgpack vs. JSON and I just want to take this chance and propose to use S-expressions instead, JSON without the syntactic bloat. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For

Channel & job design

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. For jobs the most useful are probably: - A deamon, serving several Vim instances, connect by socket. - One server working with one Vim instance,

Re: Channel & job design

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.

Re: Channel & job design

On 08-Feb-16, Bram Moolenaar wrote: > Some parts that we still need that require some thougths: > > - Communicating over a socket requires knowing the port number. For a > deamon this would be a known number. For a server started by Vim it's > best to let the server pick an available port.

Re: Channel & job design

Olaf Dabrunz wrote: > On 08-Feb-16, Bram Moolenaar wrote: > > Some parts that we still need that require some thougths: > > > > - Communicating over a socket requires knowing the port number. For a > > deamon this would be a known number. For a server started by Vim it's > > best to let

Re: Channel & job design

On Tue, Feb 09, 2016 at 01:57:32AM +0100, Bram Moolenaar wrote: > > Olaf Dabrunz wrote: > > > On 08-Feb-16, Bram Moolenaar wrote: > > > Some parts that we still need that require some thougths: > > > > > > - Communicating over a socket requires knowing the port number. For a > > > deamon