Re: [FR] Org babel: mixing multiple outputs (was: Output of R code block: only text or plot but not both? And only one "result" can be output?)

["Berry, Charles" <ccberry@health.ucsd.edu>]

> On Jun 5, 2024, at 11:17 AM, Ihor Radchenko <yantar92@posteo.net> wrote:
> 
> "Berry, Charles" <ccberry@health.ucsd.edu> writes:
> 
>>> I am trying to have an R code block output both the results of a numerical expression AND a plot, but if I set up the header arguments to display the plot, the numerical outcome is not displayed.  A simple example:
>>> 
>>> #+begin_src R :file example.png :results output graphics file
>>>  x <- rnorm(100)
>>>  print(mean(x))
>>>  hist(x)
>>> #+end_src
>>> 
>> 
>> 
>> Babel is a great tool, but has some inherent limitations.
> 
> While it is currently not directly possible to get a mix output and
> graphics results, this is _not_ inherent limitation.
> 

Fair enough, it is not `inherent'.


> One can write a patch for ob-R to produce output type that mixes all the
> block results, including textual output, graphical output, and any other
> perceivable output.

Won't you still have issues like the `:session :results output' conundrum mentioned below?

> 
> Such patch would be a reasonable addition to babel backends like ob-R or ob-python.
> 
>> Whilst you can work around this by breaking the above block into
>> multiple src blocks, you might have an easier time using ox-ravel
>> [1]. Basically, you export your *.org document to one of the
>> knitr/Rmarkdown/quarto formats (e.g. *.Rmd) and then render the final
>> output using one of those engines. This gives you access to the
>> capabilities of any of those engines.  The downside, of course, is
>> that you need to learn a bit about the formatting rules in one of them
>> to fine tune your final output.
>> 
>> FWIW, I copy and pasted your query to a `*.org` file, exported it to
>> `*.Rmd` with the latest ox-ravel version and rendered it as html -
>> displaying all the printed output and all three plots. That did not
>> need any modifications to your markup.
> 
> Thanks for sharing the project!
> Although, I would not call going through double export, and producing
> html output "easier time".
> 

The `easier' part is that knitr/Rmarkdown requires very little markup to produce nice documents in various formats (pdf, html, Word, ...). And dealing with R code and markup of the results of R code for use in documents is what that environment is attuned to, so getting a desired result often seemed easier to me in that environment.

In terms of my usual workflow, the double export (with ox-ravel and an `org-render` helper function loaded) requires these keystrokes:

`C-c C-e r m M-x org-render RET`

or subsequently

`C-u C-c C-e M-x M-p RET`

which adds only two keystrokes. 


> While we are here, are there any other features you find missing in Org
> babel that are present in knitr/Rmarkdown/quarto?
> 

`:session :results output` handling in R lang src blocks can fail as the heuristics for finding the output of a command in the session buffer and removing the prompts have limited success. An ECM:

#+begin_src R :session :results output
  cat("2 > 1\n")
#+end_src

There are workarounds, of course.

There was discussion here years ago of using an R package (evaluate?) to better parse the session results. I can't recall why this was dropped - maybe it was the requirement of additional software.

I recall hearing that `comint.el` would someday be replaced by a hardier package, so maybe if/when that happens this can be cured. 

A big motivation for creating `ox-ravel' was to be able to cache large objects. I know the `:cache` header arg helps for small objects that require a lot of computation, but AFAICS does not help once the object size gets large. The caching options [1] of knitr and friends are flexible and powerful enough to support the genomics work I do. 

I mentioned above that knitr is attuned to working with R code/output. The handling of warnings, errors, and messages resulting from R code has a number of useful options under `Text Output` [2].

I guess a rewrite of ob-R.el to implement such features as object caching and error/warning/message handling is feasible, but would require a lot of effort. And since those features (and more - like animation support) are already implemented in the knitr/Rmarkdown domain is it really worth pursuing?

Best,

Chuck 

[1] https://yihui.org/knitr/options/#cache

[2] https://yihui.org/knitr/options/#text-output