Re: [bugs] Export to HTML requires issuing org-babel-execute-buffer; results replace fails

[Leo Alekseyev <dnquark@gmail.com>]

>>
>> -----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