Luc Hermitte wrote: > I've been experimenting how to compile in background thanks to the new > job_start() feature (and without depending on Python) > > So far, I've played with two approaches where I've found some drawbacks. > Please note that if there are better ways to proceed, I'm interested to know > them. > > > 1- We plug a channel to compilation outputs with 'callback' callback. > > Pro: > - We can also register a callback to 'close_cb'. This permits to know > immediately when the compilation has finished. > > Cons: > - We need to decode manually the messages received if we wish to populate the > quickfix window on the fly. AFAIK, the internal function vim uses to decode > &makeprg outputs isn't exposed to vim scripts. > - The 'callback' callback needs to be re-entrant because it'll be re-entered. > This is quite complex to achieve if the function does too many things. For > instance, I tried to decode the message received according to &efm and then > populate the qflist from my new qf-entry, and unfortunately, the callback was > called again while the precedent call was still processing. In the end, I had > crashes.
It's not obvious to me why this function needs to be reentrant. Perhaps we still have a place where a callback is invoked when it's not "safe". I added an error message when this happens, that might not be sufficient. I already have a todo item for this, it would be helpful to know when it happens, e.g. if you have a channel log. > If I guess correctly the situation, it'll be extremely difficult to have the > 'callback' callback block until its processing is done. > > > 2- We plug a buffer to compilation outputs with 'out_io' and 'err_io' > > Pro: > - There no reentrancy issue > - A buffer can be filled and its window updated automatically as the > compilation proceeds. > > Con: > - I haven't found any way to know immediately that the internal pipe is > closed. 'close_cb' is never called. We can only rely on 'exit_cb' which isn't > as reactive > - The buffer cannot be analysed on the fly to populate the quickfix window. > > ----------------- > > So, my questions / RfCs. > - As there is also a 'buffer' and a 'file' modes for 'out_io' and 'err_io', > could we also have a 'quickfix' mode ? > I guess this is what would provide the best user experience as > - it could be built upon 'buffer' mode, > - it could have a direct access to messages decoding with &efm, > - it would be fast, > - and as a consequence it won't suffer reentrancy issue, much (as long as > another script isn't playing with setqflist/getqflist) > - it won't need to be aware the pipe is closed A quickfix mode for the channel seems a bit too specific. It's probably more useful to have a quickfix function that takes care of this. It would need an identifier for the quickfix list to add to. > - Could we have a 'close_cb' callback that get notified when a pipe > filling a buffer (or a file, or a quickfix window) is closed ? (I > don't know if this could be done) We know when the pipe gets closed, this should be possible. -- Why I like vim: > I like VIM because, when I ask a question in this newsgroup, I get a > one-line answer. With xemacs, I get a 1Kb lisp script with bugs in it ;-) /// 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.
