Luc Hermitte wrote: > > > I've been experimenting how to compile in background thanks to the > > > new job_start() feature (and without depending on Python) > > > [...] > > > > > > 1- We plug a channel to compilation outputs with 'callback' > > > callback. > > > [...] > > > - 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. > > See attached an experiment (which requires my lh-vim-lib library (1) > -- let me know if you want a minimal working example out of this) > where the callback function takes too much time to process and is > re-entered. > > Various kind of errors are possible: it ranges from strange errors > thrown from the callback function (directories popped before being > pushed), to crashes IIRC. > If we uncomment the calls to sleep, everything works fine, but this is > not realistic.
Thanks, I'll look into it later. > > > ----------------- > > > > > > 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. > > May be. If it's fast enough to never get entered multiple times > simultaneously, it'll be perfect. > > > > > - 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. > > Thanks, > > > (1) https://github.com/LucHermitte/lh-vim-lib -- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth /// 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.
