Re: [O] Error with :wrap org in babel and 8.0-pre

[John Hendy]

On Mon, Apr 15, 2013 at 5:38 PM, Eric Schulte <address@hidden> wrote:
> John Hendy <address@hidden> writes:
>
>> On Mon, Apr 15, 2013 at 3:28 PM, Eric Schulte <address@hidden> wrote:
>>> Nicolas Goaziou <address@hidden> writes:
>>>
>>>> John Hendy <address@hidden> writes:
>>>>
>>>>> On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou <address@hidden> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> John Hendy <address@hidden> writes:
>>>>>>
>>>>>>> #+RESULTS:
>>>>>>> #+BEGIN_org
>>>>>>> With the assumption of 100 lbs. of input material 1 and 200 lbs. of 
>>>>>>> material 2,
>>>>>>> we can produce the following number of widgets based on injection mold
>>>>>>> wall thicknesses.
>>>>>>> | wall  | vals | widgets  |
>>>>>>> |-------+------+----------|
>>>>>>> | 5 mil | 0.01 | 40000.00 |
>>>>>>> | 6 mil | 0.01 | 33333.00 |
>>>>>>> | 8 mil | 0.01 | 25000.00 |
>>>>>>> #+END_org
>>>>>>
>>>>>> This is wrong. We discussed it months ago on this ML and, IIRC, Babel
>>>>>> should produce "#+begin_src org" blocks, not "#+begin_org". Org
>>>>>> documentation specifies it too.
>>>>>>
>>>>>
>>>>> "Wrong," as in =:wrap org= behavior is currently a bug? Or "wrong" in
>>>>> that for my given use case, I shouldn't be using =:wrap org=?
>>>>
>>>> Wrong as is "the current behaviour is a bug". It is expected to produce
>>>> "#+begin_src org" blocks. Its use case is to generate dead data:
>>>>
>>>
>>> I disagree, the current behavior is *not* a bug.  From the manual.
>>>
>>> ,----
>>> | 14.8.2.23 ':wrap'
>>> | .................
>>> |
>>> | The ':wrap' header argument is used to mark the results of source block
>>> | evaluation.  The header argument can be passed a string that will be
>>> | appended to '#+BEGIN_' and '#+END_', which will then be used to wrap the
>>> | results.  If not string is specified then the results will be wrapped in
>>> | a '#+BEGIN/END_RESULTS' block.
>>> `----
>>>
>>> I think you're confusing ":results org" with ":wrap org".
>>>
>>> That said, I don't think there is ever a case when you would want to use
>>> ":wrap org".  The solution to the original question is to use ":results
>>> drawer".
>>
>> Here's my summary of possible options from this thread and others in
>> which I've tried to do similar things (=:exports results= used in all
>> cases):
>>
>
> Please submit patches to the documentation where it is inaccurate or
> insufficient.
>
>>
>> 1) =:results output wrap=.
>> - Documentation: none seems to suggest that this combination is even 
>> possible.
>> - Behavior: Suggested in mailing list thread with Eric Schulte and
>> works properly for me.
>>
>> 2) =:results output org=.
>> - Documentation: "The results are will be enclosed in a BEGIN_SRC org block."
>> - Behavior: Results look correct in Org buffer, but exports to LaTeX
>> in \begin/end{verbatim}.
>>
>> 3) =:results output :wrap org=.
>> - Documentation: Produces =#+begin/end_org= results block
>> - Behavior: Wraps results in \begin/end{org}, throws error on
>> compilation, but compiles into PDF correctly.
>>
>> 4) =:results output drawer=.
>> - Documentation: "The result is wrapped in a RESULTS drawer. This can
>> be useful for inserting raw or org syntax results in such a way that
>> their extent is known and they can be automatically removed or
>> replaced."
>> - Behavior: Looks correct in both .tex and resultant PDF.
>>
>> 5) =:results output raw=
>> - Documentation: "The results are interpreted as raw Org mode code and
>> are inserted directly into the buffer."
>> - Behavior: Seems like exactly what I want... but I get double results
>>
>
> I bet that this is appearing twice in the export, because with raw it is
> impossible to remove results, so if you have results existing in the
> buffer, and you are re-evaluating on export, then you'll get duplicates.
> Evaluate this code block again in the buffer and then re-export and I
> bet you'll get triplicate results. :)
>

Agreed, and this came up with you and I before on the list:
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01224.html

The solution was to do =:results output org= instead of =:results
output raw=. That's no longer the case.

>>
>> This has helped me know which work and which don't, however I still
>> find the behavior counter-intuitive and difficult to remember. For
>> example, there's no reason I would expect =wrap= or =drawer= to have
>> anything to do with what I'm trying to accomplish. I'm trying to use R
>> to spit out syntax that's Org compatible... so my intuition would be
>> to use =:results output org= (or raw) for this.
>>
>> Either way, I still find the documentation lacking. This thread has
>> motivated me to dive a bit deeper into a documentation with examples
>> of *all* results outputs, at least in R since that's what I'm used to.
>> Not sure if the behavior is tremendously different with other
>> languages. Eric, I was thinking of appending it to this page:
>> - http://orgmode.org/worg/org-contrib/babel/header-args.html
>>
>
> Sounds great.  Where your results generalize past R, please think about
> a documentation patch as well.
>
>>
>> Something perhaps with Org results and then a screenshot of side by
>> side LaTeX output?
>>
>
> Sounds great.  Thanks for helping to improve the documentation!
>

No problem. Prior to that, I have unanswered questions:
- Is the \begin/end{verbatim} wrapping the expected result for
#+begin/end_src org?

- Is =:results drawer= what we want as the syntax to get org syntax
parsed by the exporter? Just guessing from the name, it strikes me as
a fix or enhancement for some other behavior/option that's now being
applied to code as an after thought.

- Can we prune some options/syntax that's no longer necessary? For
example, what does =:wrap= (no argument provided) do? Or =:wrap src
org= / =:results output org=? It seems that these once served a
purpose but no longer accomplish anything useful.


Thanks,
John

>>
>>
>> Best regards,
>> John
>>
>>
>>
>>>
>>> Best,
>>>
>>> --
>>> Eric Schulte
>>> http://cs.unm.edu/~eschulte
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte