Ihor Radchenko <yanta...@posteo.net> writes: > Jack Kamm <jackk...@gmail.com> writes: > >> I think the correct solution would be for `org-babel-insert-result' to >> not insert file results (or any other special results) for async session >> blocks. Perhaps in this case, `org-babel-insert-result' could return a >> new result type, named "async", "future", or similar. > > That will not work. > `org-babel-comint-async-filter' expects a unique result to be inserted > into Org buffer, so that it can be located, and replaced by the async > evaluation output. > > So, we have to insert some kind of indicator for async result.
I meant that we could return something like "async:uuid-abcd-1234" or "async:/path/to/tmpfile", so that `org-babel-comint-async-filter' could still find the result. > Of course, the existing scheme of coordination between > `org-babel-insert-result' and `org-babel-comint-async-filter' is > erroneous: > > 1. We have the problem with :results file value discussed here > 2. We have a worse problem with :results file :file foo when the result > may not be unique > 3. We have :results append/prepend completely broken because > `org-babel-comint-async-filter' simply calls > `org-babel-insert-result' implicitly assuming that the existing > indicator is replaced. > > The whole thing should be re-designed. I agree that it would be good to redesign it, but am not sure where to start. A bit of a tangent, but if you are thinking about re-designing this, then it may be worth considering ob-jupyter's implementation of async sessions [1]. In particular, I believe it leaves a marker [2] where it needs to insert the future result. I don't remember the details, e.g. how it keeps track of which marker is for which result. But it seems neat, and might work better for some cases such as appending/prepending results. [1] https://github.com/emacs-jupyter/jupyter [2] https://www.gnu.org/software/emacs/manual/html_node/elisp/Markers.html
