Nathaniel Nicandro <[email protected]> writes: > Ihor Radchenko <[email protected]> writes: > >> Pete Watt-Trump <[email protected]> writes: >> >>> This is arguably an ob-jupyter bug, but the broader issue remains: there >>> is no reliable way to attach captions to results across babel backends. >>> A :result-caption header arg (or similar) would solve it portably. > > I was able to reproduce the bug on my end when executing the following: > > #+begin_src jupyter-python :session /jpy::test :async yes > from IPython.display import publish_display_data > publish_display_data({'text/org': "| A | B |\n|---+---|\n| 1 | 2 |"}) > #+end_src > > #+name: tab:summary > #+caption: Summary statistics. > #+RESULTS: > | A | B | > |---+---| > | 1 | 2 | > > It doesn't happen for synchronous source blocks since that goes through > the normal Org result insertion path. It also doesn't happen for named > source blocks that are asynchronous. I was able to trace the difference > back to org-babel-where-is-src-block-result and the fact that ob-jupyter > would have the intermediate state (during asynchronous execution) > > #+name: tab:summary > #+caption: Summary statistics. > #+RESULTS: > > when org-babel-where-is-src-block-result is called when the buffer is in > this state it sees the NAME keyword as the next element after the source > block so it doesn't think that there is a result as it doesn't know > about such sequences of keywords with a terminating RESULTS keyword as > being an empty result.
I do not see anything wrong on Org side here. Just peculiarities of how ob-jupyter implements async. Why not simply following what is done in ob-comint for async evaluation? Even better would be finishing the proper async API that is half-finished in https://list.orgmode.org/orgmode/[email protected]/ > Attached is a patch with a proposed solution which handles contiguous > keyword sequences so that org-babel-where-is-src-block-result can > recognize empty, anonymous, results. I do not think that Org mode needs to be fixed here. Our rules about location of code block results are established. I see no reason to change them. Definitely not to work around bugs in third-party packages that could as well use different approach that would not require upstream changes. Also, consider that keywords could be genuine separators like #+INCLUDE: So, your patch could also introduce problems. Canceled. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
