Hi Bram, > > > 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. > > ----------------- > > > > 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 -- Luc Hermitte -- -- 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.
job-interactive.vim
Description: Binary data
repeat-wait.sh
Description: application/shellscript
