[:results append] and [:wrap ...] don't play well together

[:results append] and [:wrap ...] don't play well together

[Greg Minshall]

hi.  this fails with [emacs -Q], which in my case
: Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)

and, also in whatever elpa'ish version i'm running
: Org mode version 9.4.4 (release_9.4.4-277-g2e1c98 @ /home/minshall/.emacs.d/straight/build/org/)

when i specify [:results append] and also [:wrap foo], the results are
not obviously appended.  below it seems as if the second evaluation is
appended, then the following are prepended after the first one?

cheers, Greg

#+begin_src elisp :results none
  (org-babel-do-load-languages
   'org-babel-load-languages
   '((emacs-lisp . t) (R . t)))
#+end_src

#+begin_src R :results append :wrap foo
Sys.time()
#+end_src

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo
#+begin_foo
2021-03-31 05:51:15
#+end_foo
#+begin_foo
2021-03-31 05:51:12
#+end_foo
#+begin_foo
2021-03-31 05:51:10
#+end_foo

[FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together

[Ihor Radchenko]

Greg Minshall <minshall@umich.edu> writes:

> hi.  this fails with [emacs -Q], which in my case
> : Org mode version 9.4.4 (release_9.4.4 @ /usr/share/emacs/27.2/lisp/org/)
>
> and, also in whatever elpa'ish version i'm running
> : Org mode version 9.4.4 (release_9.4.4-277-g2e1c98 @ /home/minshall/.emacs.d/straight/build/org/)
>
> when i specify [:results append] and also [:wrap foo], the results are
> not obviously appended.  below it seems as if the second evaluation is
> appended, then the following are prepended after the first one?

I am replying late, but let's have an explanation for this issue as a
record at least.

The observed issue is not a bug, but rather a non-intuitive behaviour.

Let me explain how Org treats the described sequence of block
executions:

#+begin_src R :results append :wrap foo
Sys.time()
#+end_src

#1:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo
<end of the results drawer; the result is first element after the block
with #+results keyword>

#2:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo
<end of the results drawer; appending a new result>
#+begin_foo
2021-03-31 05:51:10
#+end_foo

#3:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
#+end_foo
<end of the results drawer; appending a new result right here. The next
#drawer is _not_ considered a part of the result.>
#+begin_foo
2021-03-31 05:51:12
#+end_foo
#+begin_foo
2021-03-31 05:51:10
#+end_foo

And so on.

It is generally impossible to distinguish between a result consisting of
multiple paragraphs/drawers/other Org elements and the consequent
ordinary Org text. Consider:

#+begin_src elisp :results raw value
"paragraph 1

paragraph 2"
#+end_src

paragraph 3

Executing the above yields

#+begin_src elisp :results raw value
"paragraph 1

paragraph 2"
#+end_src

#+RESULTS:
paragraph 1

paragraph 2

paragraph 3

By looking at the #+RESULTS:, Org cannot possibly know if paragraph 2
belongs to the results or paragraph 3, or maybe just paragraph 1.

We may clarify this in the manual.

Another alternative could be treating
:results append drawer/code/pp/org/latex/html
differently and putting everything into a single drawer/src/export
environment like:

#+begin_src R :results append :wrap foo
Sys.time()
#+end_src

#3:

#+RESULTS:
#+begin_foo
2021-03-31 05:51:08
2021-03-31 05:51:10
2021-03-31 05:51:12
#+end_foo

However, changing the behaviour will be a breaking change, which we do
not want for the sake of back-compatibility.

Instead, we may introduce something like
:results append-contents drawer
that will behave like the above.

Is there a demand to have such a feature?

Best,
Ihor

Re: [FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together

[Greg Minshall]

Ihor,

thanks for your e-mail and explanation.

> We may clarify this in the manual.

probably worth doing.  though, trying to describe it succinctly will be
a challenge, i think!

> Another alternative could be treating
> :results append drawer/code/pp/org/latex/html
> differently and putting everything into a single drawer/src/export
> environment like:
> 
> #+begin_src R :results append :wrap foo
> Sys.time()
> #+end_src
> 
> #3:
> 
> #+RESULTS:
> #+begin_foo
> 2021-03-31 05:51:08
> 2021-03-31 05:51:10
> 2021-03-31 05:51:12
> #+end_foo
> 
> However, changing the behaviour will be a breaking change, which we do
> not want for the sake of back-compatibility.
> 
> Instead, we may introduce something like
> :results append-contents drawer
> that will behave like the above.
> 
> Is there a demand to have such a feature?

i suspect that at some point, it would be nice to have org be able to
"understand" how results of previous evaluations are laid out in the
buffer.  whether the need is now, i'm not sure (i can live without it).
(in the documentation you suggest above, it may help to have such an
option to point at; i.e., "if you don't really understand this, but want
something like this, try this option" :)

cheers, Greg