Ozaki Kiichi wrote:
> There are 2 problems about job-channel callback.
>
>
> 1) callback isn't invoked when last line doesn't terminate by NL.
>
> [repro steps]
>
> test.vim
>
> ---
> function! Callback(ch, msg)
> echom a:msg
> let g:linecount += 1
> endfunction
>
> let g:linecount = 0
> call job_start(['python', '-c', 'import sys;sys.stdout.write("1\n2\n3")'],
> {'callback': 'Callback'})
> ---
>
> vim -Nu NONE -S test.vim
>
> expected: g:linecount == 3 and ':messages shows;
>
> ----
> 1
> 2
> 3
> ----
>
> actual: g:linecount == 2 and ':messages' shows;
>
> ----
> 1
> 2
> ----
>
> [patch]
>
> - Flush last line when no ending NL
>
> https://gist.github.com/ichizok/a60b96fc5c913b260c34a7e9e1a02de8
Thanks. I was wondering if this is the right behavior, considering
there was just a discussion about systemlist() making a difference for a
missing NL at the end. But since the channel is in NL mode it's at
least not expected to drop text if the final NL is missing (or there is
no NL at all). One can use raw mode if the difference matters.
> 2) callback isn't invoked when job immediately terminates.
>
> [repro steps]
>
> test.vim
>
> ----
> function! Callback(ch, msg)
> echom a:msg
> let g:linecount += 1
> endfunction
>
> let g:linecount = 0
> call job_start(['python', '-c', 'import
> os,sys;os.close(1);sys.stderr.write("1\n")'], {'callback': 'Callback'})
> ----
>
> vim -Nu NONE -S test.vim
>
> expected: ':messages' shows "1" and g:linecount == 1
>
> actual: ':messages' shows nothing and g:linecount == 0
>
> [cause]
>
> When one of the fds associated with job-channel reachs EOF,
> job-channel are closed even if other fds has readable data.
>
> [patch]
>
> - Don't close job-channel until all readable fds are closed
>
> https://gist.github.com/ichizok/6e0c00daf387b32bebcc2972f0cca137
Nice idea, but it needs a bit more work.
Doing this with reference counting is tricky. It looks like if in
channel_set_pipes() the may_close_part() actually closes an fd, then
ch_to_be_closed is not decremented. Also, when debugging it's hard to
see what happened. I think it would work to have a bitmask: Set the
bit for the part that's opened, reset it when closed or when an error
was detected on the part. When the bitmask is zero we are done with the
channel.
The message in channel_close_on_error() that the read failed should
happen on every read fail. Thus if there is an error on stdout but
stderr is still readable, it should log "cannot read from stdout".
Otherwise we don't know what is happening.
--
MARTHA'S WAY: Don't throw out all that leftover wine. Freeze into ice cubes
for future use in casseroles and sauces.
MY WAY: What leftover wine?
/// Bram Moolenaar -- [email protected] -- 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
