search

astahlman / ob-async

Asynchronous src_block execution for org-babel
343 stars 32 forks source link

Advise all babel executions for #+NAME and #+CALL use cases #12

Closed stnutt closed 7 years ago

stnutt commented 7 years ago

This fixes #10 and #11. It's essentially what I discuss in #10. org-babel-execute-src-block is advised with the ob-async function when the ob-async package is loaded. If the block being executed does not have an :async parameter, then the unadvised org-babel-execute-src-block is called. To preserve backwards compatibility with the org-ctrl-c-ctrl-c-hook, if the ob-async function is invoked not as advice, then it gives a warning and does nothing, which allows org-babel-execute-src-block to get executed instead during ctrl-c-ctrl-c, rerunning the async function as advice, and allowing asynchronous execution to take place.

There's a new test case for the #+NAME use case, one for the #+CALL use case, and one with org-ctrl-c-ctrl-c-hook set as well.

One caveat worth discussing, is that I had to change how the code gets from the results block back to the source block. As org-babel-previous-src-block does not go back to a #+CALL. Instead, I'm calling org-backward-element twice: first to get to the beginning of the results block, and again to go to the previous element, which should be either the #+CALL or the source block. However, if there is some other element in between, then this will fail. I couldn't think of a better way that's also simple. Maybe you can think of one, or are fine with that method?

astahlman commented 7 years ago

This is great - love the tests!

Regarding finding the #+CALL or src block: I can't think of any good reason why we would need to handle a case where there's something in between the #+RESULTS block and the block that generated it. Given that the tests are green, I'm happy to keep the implementation simple. If it causes problems later we can always revisit.

I'm merging this and closing the related issues. Thanks for the pull request!