* [:results append] and [:wrap ...] don't play well together
@ 2021-03-31 2:56 Greg Minshall
2022-08-05 5:59 ` [FR, DISCUSSION] " Ihor Radchenko
0 siblings, 1 reply; 3+ messages in thread
From: Greg Minshall @ 2021-03-31 2:56 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* [FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together
2021-03-31 2:56 [:results append] and [:wrap ...] don't play well together Greg Minshall
@ 2022-08-05 5:59 ` Ihor Radchenko
2022-08-09 22:23 ` Greg Minshall
0 siblings, 1 reply; 3+ messages in thread
From: Ihor Radchenko @ 2022-08-05 5:59 UTC (permalink / raw)
To: Greg Minshall; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [FR, DISCUSSION] Re: [:results append] and [:wrap ...] don't play well together
2022-08-05 5:59 ` [FR, DISCUSSION] " Ihor Radchenko
@ 2022-08-09 22:23 ` Greg Minshall
0 siblings, 0 replies; 3+ messages in thread
From: Greg Minshall @ 2022-08-09 22:23 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-08-09 22:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-03-31 2:56 [:results append] and [:wrap ...] don't play well together Greg Minshall
2022-08-05 5:59 ` [FR, DISCUSSION] " Ihor Radchenko
2022-08-09 22:23 ` Greg Minshall
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).