* [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
@ 2012-01-21 0:25 Leo Alekseyev
2012-01-23 17:58 ` Eric Schulte
0 siblings, 1 reply; 9+ messages in thread
From: Leo Alekseyev @ 2012-01-21 0:25 UTC (permalink / raw)
To: Emacs orgmode
[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]
Since all source blocks are evaluated on export, I don't think it
should be necessary to issue org-babel-execute-buffer before invoking
export. However, running HTML export without org-babel-execute-buffer
currently produces garbage output.
On the other hand, I have several examples where running HTML export
_after_ org-babel-execute-buffer produces the wrong output due to the
fact that :results replace directive appears to append instead of
replacing the output
I am attaching three simple examples where I simulate generating and
exporting image data (I just generate and print filenames). If I
understand the documentation correctly, they are all supposed to
produce identical output on HTML export; however, none of the files
produces the expected output, namely, blocks of the form:
----
| some output
| images/conv1.png
|
| images/conv1.png
\--
Here, the first two lines should be enclosed in a code block, and the
last line should be raw org output.
To reproduce, load any of my examples, do
C-c C-e h <- will produce garbage output on export
C-c C-v b <- will produce expected output in the buffer
C-c C-e h <- will produce extraneous output on export despite :results
replace being on
C-c C-v b <- will produce extraneous output in the buffer
This was tested on my test-export4.org, but the other examples behave
in a similar fashion.
--Leo
[-- Attachment #2: test-export4.org --]
[-- Type: application/octet-stream, Size: 843 bytes --]
#+property: session *R-babel*
* export fail
#+NAME: foo
#+HEADER: :var idx=1 :var print="TRUE" :var plot.filename="conv1.png" :var plot.disp="FALSE"
#+BEGIN_SRC R :results output silent
if (print == TRUE) {cat("some output\n")}
img.dir = "images"
cat.fname.link <- function() { cat(img.dir,"/",plot.filename,"\n",sep="") }
cat.fname.link()
#+END_SRC
Should have all conv1 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv1.png",plot.disp="FALSE")
src_R[:results output replace]{ cat.fname.link() }
Should have all conv2 stuff
#+call: foo(idx=8,print="TRUE",plot.filename="conv2.png",plot.disp="FALSE")
src_R[:results output replace]{ cat.fname.link() }
Should have all conv3 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv3.png",plot.disp="FALSE")
src_R[:results output replace]{ cat.fname.link() }
[-- Attachment #3: test-export5.org --]
[-- Type: application/octet-stream, Size: 953 bytes --]
#+property: session *R-babel*
* export fail
#+NAME: foo
#+HEADER: :var idx=1 :var print="TRUE" :var plot.filename="conv1.png" :var plot.disp="FALSE"
#+BEGIN_SRC R :results output silent
if (print == TRUE) {cat("some output\n")}
img.dir = "images"
cat.fname.link <- function() { cat(img.dir,"/",plot.filename,"\n",sep="") }
cat.fname.link()
#+END_SRC
Should have all conv1 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv1.png",plot.disp="FALSE")
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
Should have all conv2 stuff
#+call: foo(idx=8,print="TRUE",plot.filename="conv2.png",plot.disp="FALSE")
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
Should have all conv3 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv3.png",plot.disp="FALSE")
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
[-- Attachment #4: test-export7.org --]
[-- Type: application/octet-stream, Size: 885 bytes --]
#+property: session *R-babel*
* export fail
#+NAME: foo
#+HEADER: :var idx=1 :var print="TRUE" :var plot.filename="conv1.png" :var plot.disp="FALSE"
#+BEGIN_SRC R :results output silent
if (print == TRUE) {cat("some output\n")}
img.dir = "images"
cat.fname.link <- function() { cat(img.dir,"/",plot.filename,"\n",sep="") }
cat.fname.link()
#+END_SRC
#+NAME: bar
#+begin_src R :results output raw replace :exports none
cat.fname.link()
#+end_src
Should have all conv1 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv1.png",plot.disp="FALSE")
#+call: bar[:exports results]()
Should have all conv2 stuff
#+call: foo(idx=8,print="TRUE",plot.filename="conv2.png",plot.disp="FALSE")
#+call: bar[:exports results]()
Should have all conv3 stuff
#+call: foo(idx=1,print="TRUE",plot.filename="conv3.png",plot.disp="FALSE")
#+call: bar[:exports results]()
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-21 0:25 [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails Leo Alekseyev
@ 2012-01-23 17:58 ` Eric Schulte
2012-01-24 3:50 ` Leo Alekseyev
0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2012-01-23 17:58 UTC (permalink / raw)
To: Leo Alekseyev; +Cc: Emacs orgmode
Leo Alekseyev <dnquark@gmail.com> writes:
> Since all source blocks are evaluated on export, I don't think it
> should be necessary to issue org-babel-execute-buffer before invoking
> export. However, running HTML export without org-babel-execute-buffer
> currently produces garbage output.
>
What do you mean by "garbage" output?
>
> On the other hand, I have several examples where running HTML export
> _after_ org-babel-execute-buffer produces the wrong output due to the
> fact that :results replace directive appears to append instead of
> replacing the output
>
Could you isolate a minimal example demonstrating just the failure of
results replacement?
Thanks,
>
> I am attaching three simple examples where I simulate generating and
> exporting image data (I just generate and print filenames). If I
> understand the documentation correctly, they are all supposed to
> produce identical output on HTML export; however, none of the files
> produces the expected output, namely, blocks of the form:
>
> ----
> | some output
> | images/conv1.png
> |
> | images/conv1.png
> \--
>
> Here, the first two lines should be enclosed in a code block, and the
> last line should be raw org output.
>
> To reproduce, load any of my examples, do
>
> C-c C-e h <- will produce garbage output on export
> C-c C-v b <- will produce expected output in the buffer
> C-c C-e h <- will produce extraneous output on export despite :results
> replace being on
> C-c C-v b <- will produce extraneous output in the buffer
>
> This was tested on my test-export4.org, but the other examples behave
> in a similar fashion.
>
> --Leo
>
>
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-23 17:58 ` Eric Schulte
@ 2012-01-24 3:50 ` Leo Alekseyev
2012-01-24 4:05 ` Eric Schulte
0 siblings, 1 reply; 9+ messages in thread
From: Leo Alekseyev @ 2012-01-24 3:50 UTC (permalink / raw)
To: Eric Schulte; +Cc: Emacs orgmode
On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte <eric.schulte@gmx.com> wrote:
> Leo Alekseyev <dnquark@gmail.com> writes:
>
>> Since all source blocks are evaluated on export, I don't think it
>> should be necessary to issue org-babel-execute-buffer before invoking
>> export. However, running HTML export without org-babel-execute-buffer
>> currently produces garbage output.
>>
>
> What do you mean by "garbage" output?
That wasn't a very good description, sorry.
......
I just wrote a detailed description of the bug, and then remembered
that I forgot to copy the latest org pull into
/usr/share/emacs/24/lisp/org. This bug is now gone, probably as a
result of you fixing export evaluation order. However, the
description of "replace results" bug is still relevant. I'll denote
issues that are now fixed with appropriate markup.
#+BEGIN_MOOT_POINT
Take test-export4.org from my original message, and export (C-c C-e h;
don't evaluate the buffer beforehand). You will see the following
output: http://i.imgur.com/IM3oy.png
There are two problems:
(1) Notice that the output of _every_ src_R block is "images/conv2.png"
It should be "conv1.png" on the first invocation "conv2.png" on the
second, and "conv3.png" on the third.
(2) The last src_R block is not evaluated and, in fact, appears in the
output (which it shouldn't), mangled, as the underscore is taken as a
subscript.
#+END_MOOT_POINT
For comparison, if you first evaluate the buffer, and then export, you
will see this:
http://i.imgur.com/V6PXq.png
The output of the src_R blocks is now correct, but I don't see why one
needs to pre-evaluate the buffer to get correct output on export. The
overall output, as you can see, is _not_ correct, since the results
from invocation of src_R blocks via the export are _appended_ to those
that were generated via C-c C-v b.
>
> Could you isolate a minimal example demonstrating just the failure of
> results replacement?
Run the below code a few times with C-c C-v b, and you'll see
------------snip---------
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var plot.filename="conv1.png"
#+BEGIN_SRC R :results output silent
cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
cat.fname.link()
#+END_SRC
src_R[:results output replace]{ cat.fname.link() }
------------snip---------
You can also replace src_R with
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
and it will also fail to replace results.
All the above examples were run with the latest pull of org.
HTH,
--Leo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-24 3:50 ` Leo Alekseyev
@ 2012-01-24 4:05 ` Eric Schulte
2012-01-24 4:53 ` Leo Alekseyev
0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2012-01-24 4:05 UTC (permalink / raw)
To: Leo Alekseyev; +Cc: Emacs orgmode
Leo Alekseyev <dnquark@gmail.com> writes:
> On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte <eric.schulte@gmx.com> wrote:
>> Leo Alekseyev <dnquark@gmail.com> writes:
>>
>>> Since all source blocks are evaluated on export, I don't think it
>>> should be necessary to issue org-babel-execute-buffer before invoking
>>> export. However, running HTML export without org-babel-execute-buffer
>>> currently produces garbage output.
>>>
>>
>> What do you mean by "garbage" output?
>
> That wasn't a very good description, sorry.
No problem, thanks for clarifying.
[... moot bug removed ...]
>>
>> Could you isolate a minimal example demonstrating just the failure of
>> results replacement?
>
> Run the below code a few times with C-c C-v b, and you'll see
>
> ------------snip---------
> #+property: session *R-babel*
>
> #+NAME: foo
> #+HEADER: :var plot.filename="conv1.png"
> #+BEGIN_SRC R :results output silent
> cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
> cat.fname.link()
> #+END_SRC
>
> src_R[:results output replace]{ cat.fname.link() }
> ------------snip---------
>
>
> You can also replace src_R with
>
> #+begin_src R :results output raw replace :exports results
> cat.fname.link()
> #+end_src
>
> and it will also fail to replace results.
>
> All the above examples were run with the latest pull of org.
>
Ah, I see now. Unfortunately it is not possible to replace the results
of inline code blocks. This is because there is no general way to
identify where the results begin and end. Maybe adding [:results
silent] to your inline code blocks would solve the problem. Then you
could evaluate the whole buffer, and could previews the values produced,
but would not have to worry about duplicate results.
Sorry I don't have a more satisfying answer.
Best,
>
> HTH,
>
> --Leo
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-24 4:05 ` Eric Schulte
@ 2012-01-24 4:53 ` Leo Alekseyev
2012-01-24 14:52 ` Eric Schulte
0 siblings, 1 reply; 9+ messages in thread
From: Leo Alekseyev @ 2012-01-24 4:53 UTC (permalink / raw)
To: Eric Schulte; +Cc: Emacs orgmode
On Mon, Jan 23, 2012 at 10:05 PM, Eric Schulte <eric.schulte@gmx.com> wrote:
> Leo Alekseyev <dnquark@gmail.com> writes:
>
>> On Mon, Jan 23, 2012 at 11:58 AM, Eric Schulte <eric.schulte@gmx.com> wrote:
>>> Leo Alekseyev <dnquark@gmail.com> writes:
>>>
>>>> Since all source blocks are evaluated on export, I don't think it
>>>> should be necessary to issue org-babel-execute-buffer before invoking
>>>> export. However, running HTML export without org-babel-execute-buffer
>>>> currently produces garbage output.
>>>>
>>>
>>> What do you mean by "garbage" output?
>>
>> That wasn't a very good description, sorry.
>
> No problem, thanks for clarifying.
>
> [... moot bug removed ...]
>
>>>
>>> Could you isolate a minimal example demonstrating just the failure of
>>> results replacement?
>>
>> Run the below code a few times with C-c C-v b, and you'll see
>>
>> ------------snip---------
>> #+property: session *R-babel*
>>
>> #+NAME: foo
>> #+HEADER: :var plot.filename="conv1.png"
>> #+BEGIN_SRC R :results output silent
>> cat.fname.link <- function() { cat(plot.filename,"\n",sep="") }
>> cat.fname.link()
>> #+END_SRC
>>
>> src_R[:results output replace]{ cat.fname.link() }
>> ------------snip---------
>>
>>
>> You can also replace src_R with
>>
>> #+begin_src R :results output raw replace :exports results
>> cat.fname.link()
>> #+end_src
>>
>> and it will also fail to replace results.
>>
>> All the above examples were run with the latest pull of org.
>>
>
> Ah, I see now. Unfortunately it is not possible to replace the results
> of inline code blocks. This is because there is no general way to
> identify where the results begin and end. Maybe adding [:results
> silent] to your inline code blocks would solve the problem. Then you
> could evaluate the whole buffer, and could previews the values produced,
> but would not have to worry about duplicate results.
Yes, that's a good suggestion.
Just to be clear, do you consider the following to be an inline block?
(I usually think of inline as limited to src_R{ ...} type things).
Or are you generally talking about the distinction between #+begin_src
/ #+end_src lines vs #+call lines?
#+begin_src R :results output raw replace :exports results
cat.fname.link()
#+end_src
Finally, in the last file of my original message I try to use #+call's
everywhere instead of source blocks. Cleaned up example is pasted
below. It looks broken (the first #+call bar is out of order, the
second and third #+call bar's don't run), see
http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
broken
----------snip---------
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var a="a1.png"
#+BEGIN_SRC R :results output silent
cat("in foo block\n")
cat.a <- function() { cat(a,"\n",sep="") }
cat.a()
#+END_SRC
#+NAME: bar
#+begin_src R :results output raw replace :exports none
cat.a()
#+end_src
Should have all a1 stuff
#+call: foo(a="a1.png")
#+call: bar()
Should have all a2 stuff
#+call: foo(a="a2.png")
#+call: bar()
Should have all a3 stuff
#+call: foo(a="a3.png")
#+call: bar()
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-24 4:53 ` Leo Alekseyev
@ 2012-01-24 14:52 ` Eric Schulte
2012-01-24 23:35 ` Leo Alekseyev
0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2012-01-24 14:52 UTC (permalink / raw)
To: Leo Alekseyev; +Cc: Emacs orgmode, Eric Schulte
>
> Just to be clear, do you consider the following to be an inline block?
> (I usually think of inline as limited to src_R{ ...} type things).
> Or are you generally talking about the distinction between #+begin_src
> / #+end_src lines vs #+call lines?
>
> #+begin_src R :results output raw replace :exports results
> cat.fname.link()
> #+end_src
>
My terminology is
inline block :: src_foo{} which can live on a line with text
block :: begin/end_src foo, which is a block element
call line :: #+call: which lives on a block by itself
If /inline blocks/ above don't replace their results above then that is
expected. If you can find instances where call lines or blocks don't
replace their results then that is a bug.
>
> Finally, in the last file of my original message I try to use #+call's
> everywhere instead of source blocks. Cleaned up example is pasted
> below. It looks broken (the first #+call bar is out of order, the
> second and third #+call bar's don't run), see
> http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
> broken
>
Ah, this is a different issue, but one which should be discussed. I'm
happy we're working through all of these before the Emacs24 release.
The problem below is not order of evaluation but rather insertion of
results. The elements are evaluated in order, but the results from the
bar() call lines are all inserted in the same place. In the current
code the raw text of the call line is used to insert the results, so
identical call lines replace each other's results.
So in the following...
#+NAME: foo-for-R
#+HEADER: :var a="a1.png"
#+BEGIN_SRC R :results output silent
cat("in foo-for-R block\n")
cat.a <- function() { cat(a,"\n",sep="") }
cat.a()
#+END_SRC
#+NAME: bar-for-R
#+begin_src R :results output raw replace :exports none
cat.a()
#+end_src
Because there are three instances of the =bar-for-R()= call line, all of
their results are inserted into the same place in the file, specifically
the location of the =#+Results: bar-for-R()= line. This can be very
confusing if you are expected each =bar-for-R()= line to generate it's
own results.
Should have all a1 stuff
#+call: foo-for-R(a="a1.png")
#+call: bar-for-R()
Should have all a2 stuff
#+call: foo-for-R(a="a2.png")
#+call: bar-for-R()
Should have all a3 stuff
#+call: foo-for-R(a="a3.png")
#+call: bar-for-R()
The solution demonstrated below is to add a nothing header argument to
each bar-for-R to make it unique. Notice that the three =foo= lines
below don't include results, as their results are inserted at the
identical foo lines above.
Should have all a1 stuff
#+call: foo-for-R(a="a1.png")
#+call: bar-for-R[id=1]()
Should have all a2 stuff
#+call: foo-for-R(a="a2.png")
#+call: bar-for-R[id=2]()
Should have all a3 stuff
#+call: foo-for-R(a="a3.png")
#+call: bar-for-R[id=3]()
Although the above is a workaround, it may be cumbersome. I'm on the
fence about whether to try to change the existing behavior. If each
identical call line is thought of as a token of the same call then maybe
it makes sense to have only one location in which to insert the results
of that call (also it is possible that some users are relying on the
current behavior). That said it is certainly confusing...
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-24 14:52 ` Eric Schulte
@ 2012-01-24 23:35 ` Leo Alekseyev
2012-01-27 22:43 ` Eric Schulte
0 siblings, 1 reply; 9+ messages in thread
From: Leo Alekseyev @ 2012-01-24 23:35 UTC (permalink / raw)
To: Eric Schulte; +Cc: Emacs orgmode
>
> If /inline blocks/ above don't replace their results above then that is
> expected. If you can find instances where call lines or blocks don't
> replace their results then that is a bug.
Yes, I was finding that neither inline nor regular blocks replace: run
the following with C-c C-v b a few times and look at the block output
-----snip------
#+property: session *R-babel*
#+NAME: foo
#+HEADER: :var a="a1.png"
#+BEGIN_SRC R :results output silent
cat("in foo block\n")
cat.a <- function() { cat(a,"\n",sep="") }
cat.a()
#+END_SRC
#+call: foo(a="a1.png")
#+begin_src R :results output raw replace :exports results
cat.a()
#+end_src
----------snip---------
>
>>
>> Finally, in the last file of my original message I try to use #+call's
>> everywhere instead of source blocks. Cleaned up example is pasted
>> below. It looks broken (the first #+call bar is out of order, the
>> second and third #+call bar's don't run), see
>> http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
>> broken
>>
>
> Ah, this is a different issue, but one which should be discussed. I'm
> happy we're working through all of these before the Emacs24 release.
>
> The problem below is not order of evaluation but rather insertion of
> results. The elements are evaluated in order, but the results from the
> bar() call lines are all inserted in the same place. In the current
> code the raw text of the call line is used to insert the results, so
> identical call lines replace each other's results.
.......
>> Although the above is a workaround, it may be cumbersome. I'm on the
> fence about whether to try to change the existing behavior. If each
> identical call line is thought of as a token of the same call then maybe
> it makes sense to have only one location in which to insert the results
> of that call (also it is possible that some users are relying on the
> current behavior). That said it is certainly confusing...
I see no reason why we should think of each call line as a token of
the same call; do you? In fact, it's probably a fundamentally flawed
way of thinking, because nothing guarantees that the global state of
the session hasn't changed between call invocations. In fact, in that
sense, we can't even technically regard the _same_ call line as being
a token of the same call, if we consider it at different times :)
Referring to what I said in another thread ("the principle of least
surprise"): it makes a lot of sense for the call lines to behave the
same way a function call, or a source() statement would behave in the
interpreter session of the original language. From that perspective,
the current behavior seems wrong. Can you come up with a scenario /
usage pattern where the current behavior is more desirable?
--Leo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-24 23:35 ` Leo Alekseyev
@ 2012-01-27 22:43 ` Eric Schulte
2012-01-28 23:07 ` Leo Alekseyev
0 siblings, 1 reply; 9+ messages in thread
From: Eric Schulte @ 2012-01-27 22:43 UTC (permalink / raw)
To: Leo Alekseyev; +Cc: Emacs orgmode, Eric Schulte
Leo Alekseyev <dnquark@gmail.com> writes:
>>
>> If /inline blocks/ above don't replace their results above then that is
>> expected. If you can find instances where call lines or blocks don't
>> replace their results then that is a bug.
>
> Yes, I was finding that neither inline nor regular blocks replace: run
> the following with C-c C-v b a few times and look at the block output
>
> -----snip------
> #+property: session *R-babel*
>
> #+NAME: foo
> #+HEADER: :var a="a1.png"
> #+BEGIN_SRC R :results output silent
> cat("in foo block\n")
> cat.a <- function() { cat(a,"\n",sep="") }
> cat.a()
> #+END_SRC
> #+call: foo(a="a1.png")
>
> #+begin_src R :results output raw replace :exports results
> cat.a()
> #+end_src
> ----------snip---------
>
OK, I see what you mean. When I evaluate this buffer multiple times the
results of the #+call: line *are* replaced as expected, but the final
code block can not replace it's results because of the "raw" option to
the :results header argument. The "raw" and "replace" header arguments
are not compatible because with raw results there is no way to know
where the results end. I believe this is mentioned in the manual, if
not it should be.
>
>
>>
>>>
>>> Finally, in the last file of my original message I try to use #+call's
>>> everywhere instead of source blocks. Cleaned up example is pasted
>>> below. It looks broken (the first #+call bar is out of order, the
>>> second and third #+call bar's don't run), see
>>> http://pastebin.com/LqYK0Ps2 with my annotation where the output looks
>>> broken
>>>
>>
>> Ah, this is a different issue, but one which should be discussed. I'm
>> happy we're working through all of these before the Emacs24 release.
>>
>> The problem below is not order of evaluation but rather insertion of
>> results. The elements are evaluated in order, but the results from the
>> bar() call lines are all inserted in the same place. In the current
>> code the raw text of the call line is used to insert the results, so
>> identical call lines replace each other's results.
>
> .......
>
>>> Although the above is a workaround, it may be cumbersome. I'm on the
>> fence about whether to try to change the existing behavior. If each
>> identical call line is thought of as a token of the same call then maybe
>> it makes sense to have only one location in which to insert the results
>> of that call (also it is possible that some users are relying on the
>> current behavior). That said it is certainly confusing...
>
> I see no reason why we should think of each call line as a token of
> the same call; do you? In fact, it's probably a fundamentally flawed
> way of thinking, because nothing guarantees that the global state of
> the session hasn't changed between call invocations. In fact, in that
> sense, we can't even technically regard the _same_ call line as being
> a token of the same call, if we consider it at different times :)
>
I'm inclined to agree with you.
>
> Referring to what I said in another thread ("the principle of least
> surprise"): it makes a lot of sense for the call lines to behave the
> same way a function call, or a source() statement would behave in the
> interpreter session of the original language. From that perspective,
> the current behavior seems wrong. Can you come up with a scenario /
> usage pattern where the current behavior is more desirable?
>
The only loss of functionality would be the ability in the existing
model to have a call line and it's results live in separate locations.
Given that call lines can not currently be named their results are named
by the information on the call line (called function, header arguments,
etc...) which will be identical for identical call lines, leading to the
current confusing behavior.
I think the best way forward would be to
1. stop auto-naming #+call: lines as we are currently and instead leave
their results anonymous as with code blocks, and by default inserted
immediately after the #+call: line.
2. allow names to be applied to call lines, which can then be used to
identify their results and locate their results remotely in the
buffer.
If this sounds like a good way forward then I'll put it on my queue for
some time in the when-I-have-more-time future. :)
Best,
>
> --Leo
>
--
Eric Schulte
http://cs.unm.edu/~eschulte/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails
2012-01-27 22:43 ` Eric Schulte
@ 2012-01-28 23:07 ` Leo Alekseyev
0 siblings, 0 replies; 9+ messages in thread
From: Leo Alekseyev @ 2012-01-28 23:07 UTC (permalink / raw)
To: Eric Schulte; +Cc: Emacs orgmode
>>
>> -----snip------
>> #+property: session *R-babel*
>>
>> #+NAME: foo
>> #+HEADER: :var a="a1.png"
>> #+BEGIN_SRC R :results output silent
>> cat("in foo block\n")
>> cat.a <- function() { cat(a,"\n",sep="") }
>> cat.a()
>> #+END_SRC
>> #+call: foo(a="a1.png")
>>
>> #+begin_src R :results output raw replace :exports results
>> cat.a()
>> #+end_src
>> ----------snip---------
>>
>
> OK, I see what you mean. When I evaluate this buffer multiple times the
> results of the #+call: line *are* replaced as expected, but the final
> code block can not replace it's results because of the "raw" option to
> the :results header argument. The "raw" and "replace" header arguments
> are not compatible because with raw results there is no way to know
> where the results end. I believe this is mentioned in the manual, if
> not it should be.
Ok, I see. Ideally, incompatible arguments should trigger an error
condition that would be communicated to the user (at the very least,
by printing a message in the minibuffer). Silent failures are
annoying, even if documented :)
On a more practical note, is there _a_ method of achieving what I'm
trying to do here, namely, to place an image in the buffer in a way
that would be understood by Org and that would be properly imported in
HTML?
>> Referring to what I said in another thread ("the principle of least
>> surprise"): it makes a lot of sense for the call lines to behave the
>> same way a function call, or a source() statement would behave in the
>> interpreter session of the original language. From that perspective,
>> the current behavior seems wrong. Can you come up with a scenario /
>> usage pattern where the current behavior is more desirable?
>>
>
> The only loss of functionality would be the ability in the existing
> model to have a call line and it's results live in separate locations.
> Given that call lines can not currently be named their results are named
> by the information on the call line (called function, header arguments,
> etc...) which will be identical for identical call lines, leading to the
> current confusing behavior.
>
> I think the best way forward would be to
>
> 1. stop auto-naming #+call: lines as we are currently and instead leave
> their results anonymous as with code blocks, and by default inserted
> immediately after the #+call: line.
>
> 2. allow names to be applied to call lines, which can then be used to
> identify their results and locate their results remotely in the
> buffer.
>
> If this sounds like a good way forward then I'll put it on my queue for
> some time in the when-I-have-more-time future. :)
Yes, I think it's a good long-term plan. Enqueue it :) In the
meantime, the current behavior (and the possible workaround) should
probably be mentioned in the docs if it isn't already.
--Leo
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-01-28 23:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-21 0:25 [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails Leo Alekseyev
2012-01-23 17:58 ` Eric Schulte
2012-01-24 3:50 ` Leo Alekseyev
2012-01-24 4:05 ` Eric Schulte
2012-01-24 4:53 ` Leo Alekseyev
2012-01-24 14:52 ` Eric Schulte
2012-01-24 23:35 ` Leo Alekseyev
2012-01-27 22:43 ` Eric Schulte
2012-01-28 23:07 ` Leo Alekseyev
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).