(Maybe) better handling of background evaluation in ob-julia

[MasonProtter]

Okay, so before this change, I sent code to the julia session using julia-snail's async method, and this worked, but if the user interacted with emacs between them hitting C-c C-c and the computation finishing, then no result would actually end up in the results drawer. This is an experiment in fixing that by now not using julia-snail's async kwarg, but instead making a new function meant to replace usage of org-ctrl-c-ctrl-c that runs inside a thread that is allowed to yield's while waiting for the julia process to finish.

This approach has the downside of requiring users to remap C-c C-c from org-ctrl-c-ctrl-c to julia-snail/ob-julia-ctrl-c-ctrl-c, but I think the result is worth it because it makes the printing of results more reliable.

I might not have done it in the most sane way though as I don't know much about async emacs and the many foot-guns with trying to be clever when moving around point, so if you have any thoughts on how to improve this it'd be much appreciated.

[gcv]

I have not played with Emacs threads, so can't comment on potential pitfalls. If you think this approach works better, that's good enough for me.

On the matter of rebinding C-c C-c, you can avoid it by making an :around advice for org-ctrl-c-ctrl-c that checks if (point) is on a Julia src block, and if it is, using your custom logic. If not, fall back to normal behavior. Enable the advice in the ob-julia minor mode along with the completion-at-point function. Make sure you use the newer advice mechanism (add-advice), the old one still works but is a little harder to understand.

[MasonProtter]

Ah I had seen you mention advice before and meant to read about it but never got around to it. This is perfect, thanks!

[MasonProtter]

Okay, when everything goes right, things are working quite well now, but I am getting occasional crashes, so let's not merge this until I figure out what's going on.

[gcv]

I played with it a bit, and noticed the following:

1. ob-julia--point-inits and ob-julia--point-finals need to be declared before org-babel-execute:julia because they're referenced.
2. julia-snail/ob-julia--point-hash is unused; remove it?
3. The code you put back for starting julia-snail if it isn't already running causes this error the first time, which I think you know about: let: Wrong type argument: integer-or-marker-p, nil. It can probably be debugged, but while doing so, I discovered the following: changing the definition of julia-snail/ob-julia-evaluate does not always work. I didn't get to the bottom of why, but I suspect babel does some tricky caching somewhere.

Other than that, the branch seems to work for me on some casual testing. I wonder if some of the trouble you ran into has to do with the way babel executes.

[MasonProtter]

@gcv okay, I think this is now ready now. Sorry I took much longer to address these kinda minor problems than I intended.

This also fixes an incompatability with versions 1.6 and earlier that I accidentally caused by using redirect_io.

[gcv]

Just a couple of things in the README:

Once the extension is enabled, Org Babel commands should work on Julia code as expected, and the first time you execute a block, it'll automatically start a julia-snail session if no existing session is running.

I don't think that works.

Be default, executing a source block will lock emacs until the source block finishes running, however if instead of using the function org-ctrl-c-ctrl-c (bound to C-c C-c inside org-mode buffers), you use julia-snail/ob-julia-ctrl-c-ctrl-c (I recommend binding it to C-c C-c), then you can continue editing files while code runs.

That's no longer true, right?

[MasonProtter]

Oops, good catch.