Re: [O] Asynchronous session evaluation

[Nicolas Goaziou]

Hello,

Jack Kamm <address@hidden> writes:

> For some time I've been wishing for asynchronous Babel session
> evaluation. So I've created an experimental branch implementing this. I
> have an initial version working for R, so I thought it'd be a good time
> to seek feedback and gauge interest.
>
> To test the attached patch, add ":async yes" to an R session block
> with a long computation (or "System.sleep") in it. Upon evaluation,
> your Emacs won't freeze to wait for the result -- instead, a
> placeholder will be inserted, and replaced with the true result when
> it's ready.
>
> I'll note how this is different from some related projects. ob-async
> implements asynchronous evaluation for Babel, but it doesn't work with
> sessions. emacs-jupyter, ein, and ob-ipython all implement asynchronous
> session evaluation, but only for Jupyter kernels. Jupyter is great for
> some cases, but sometimes I'd prefer not to use it. For example, the
> native R console has great Emacs support via ESS, whereas the Jupyter R
> console doesn't work with ESS and is not widely used in the R community.
>
> Note that if you use ob-async, make sure to add "R" to
> `ob-async-no-async-languages-alist' before testing this.
>
> The new functionality is mainly implemented in
> `org-babel-comint-async-filter', which I've defined in ob-comint.el,
> and added as a hook to `comint-output-filter-functions'.  Whenever new
> output is added to the comint buffer, the filter scans for an
> indicator token (this is inspired by
> `org-babel-comint-with-output'). Upon encountering the token, the
> filter uses a regular expression to extract a UUID or temp-file
> associated with the result, then searches for the appropriate location
> to add the result to.
>
> I've tried to make behavior as similar as possible to existing
> ob-comint behavior, so that some of the existing code for interacting
> with ob-comint can be refactored and reused. Still, it will be a large
> task to add this feature for all languages. So far, I've only done R,
> but my thought is to implement a few more languages before nailing
> down the functionality. But, I hope something like this could be
> merged in supporting just a subset of languages initially, then
> gradually increasing the number of supported languages over time.

This sound interesting. I hope this is not going to bit-rot while we're
waiting for feedback.

If you think this is stable enough, however, you could simply integrate
in the master branch after Org 9.3 release. It would require an entry in
ORG-NEWS, though.

WDYT?

Regards,

-- 
Nicolas Goaziou