Bruno Barbier <brubar...@gmail.com> writes: > FWIW, I've been trying to use asynchronous blocks for everything, not > only the source blocks that are based on the comint mode. I think it > would be good if ob-core itself could provide an asynchronous API. I've > modified my Org so that it does have such an API. This is work in > progress; let me describe it. > > I've modified ob-core itself to allow asynchronicity. In the > asynchrosous case, instead of calling: > > (org-babel-execute:LANG body params) > > I'm calling: > > (org-babel-schedule:LANG body params handle-result) > > where `org-babel-schedule:LANG' is in charge of calling `handle-result' > with the result (or the error) when it is known; `handle-result' takes > care to call `org-babel-insert-result' at the correct place (and > `org-babel-insert-result' is only called with a real result).
Sounds interesting, a couple questions: 1. Which languages have you implemented/tested this on? 2. Does it apply for sessions, nonsessions, or both? > While the execution is pending, I'm using the same technique that Org is > using when a source block is being edited: the result is left untouched, > but below an overlay. The overlay is used to know where to insert the > result and to display the status/progress of the execution. If the file > is closed and the execution fails, nothing is lost, the old result is > still available. Also interesting, I think it's worth exploring/testing this overlay idea out. Does that mean that output is asynchronously printing into the Org buffer? It sounds cool but I wonder if it might cause problems while trying to edit another part of the buffer.
