Andrew Stewart wrote:
> > On 26 Apr 2016, at 8:38 pm, Bram Moolenaar <b...@moolenaar.net> wrote:
> >
> > You can now use ch_status() for that. If it returns "open" or
> > "buffered" there may be more to read. When "closed" then it's done.
> >
> > I have added this example in the help:
> >
> > func! CloseHandler(channel)
> > while ch_status(a:channel) == 'buffered'
> > echomsg ch_read(a:channel)
> > endwhile
> > endfunc
> > let job = job_start(command, {'close_cb': 'CloseHandler'})
>
> Should the condition be `while ch_status(a:channel) == 'buffered' ||
> ch_status(a:channel) == 'open'` as per the description?
>
> I upgraded to 7.4.1795 and tried out the example as is.
>
> I couldn't find the example in the help.
>
> Every few callbacks the screen needed a `:redraw!` to:
>
> - display the correct signs (my handler updates them)
> - display the cursor in the correct position (getpos('.') showed the right
> coordinates but the cursor was displayed elsewhere).
It's expected that the handler has to tell Vim what needs to be redrawn.
There is some redrawing after the callback returns, but things like
"echomsg" can mess up the screen, especially if it causes scrolling.
> I haven't been able to reproduce this consistently. I tried adding a
> `redraw`/`redraw!` as the last line of my handler but it didn't make
> any difference.
>
> Every few dozen callbacks `ch_read(a:channel)` threw an E906 error,
> though again I'm not able to reproduce it consistently. Perhaps there
> is a race condition where the channel is closed between checking its
> status and reading from it? I modified my handler to:
>
> function! CloseHandler(channel)
> let output = ''
> try
> while ch_status(a:channel) == 'buffered'
> let line = ch_read(a:channel)
> if line !=# 'DETACH'
Note that adding "DETACH" was removed, so you can drop this check.
> let output .= line."\n"
> endif
> endwhile
> echom output
> endfunction
>
> ...which seemed to work well, at least until Vim crashed:
>
> Vim: Caught deadly signal SEGV
> Vim(85664,0x7fff7a952000) malloc: *** error for object 0x7ff2106739e8:
> incorrect checksum for freed object - object was probably modified after
> being freed.
> *** set a breakpoint in
> malloc_error_break to debug
>
> Vim: Finished.
> Vim: Double signal, exiting
> Abort trap: 6
>
> I don't know how to set a breakpoint in malloc_error_break so I wasn't
> able to debug this, sorry. When it happened there was nothing unusual
> in the channel log.
A couple of problems have been fixed. Please give it another try and
report back if you still see a problem.
> I also implemented my job_start using an out_cb handler again instead
> of a close_cb handler. The occasional-missing-callback problem has
> disappeared and it all worked perfectly. Thanks!
That is the preferred way. Reading the output in the close callback
might only work if there isn't much to read.
--
Close your shells, or I'll kill -9 you
Tomorrow I'll quota you
Remember the disks'll always be full
And then while I'm away
I'll write ~ everyday
And I'll send-pr all my buggings to you.
[ CVS log "Beatles style" for FreeBSD ports/INDEX, Satoshi Asami ]
/// 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.
