From: John Hendy <jw.hendy@gmail.com>
To: Eric Schulte <schulte.eric@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>,
Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: Error with :wrap org in babel and 8.0-pre
Date: Mon, 15 Apr 2013 17:48:19 -0500 [thread overview]
Message-ID: <CA+M2ft_mFPvyn_Jry-D7rVamzOoY+c+ozC=JcZAno=XLu=B6kQ@mail.gmail.com> (raw)
In-Reply-To: <87sj2re7xl.fsf@gmail.com>
On Mon, Apr 15, 2013 at 5:38 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> John Hendy <jw.hendy@gmail.com> writes:
>
>> On Mon, Apr 15, 2013 at 3:28 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>
>>>> John Hendy <jw.hendy@gmail.com> writes:
>>>>
>>>>> On Mon, Apr 15, 2013 at 2:56 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> John Hendy <jw.hendy@gmail.com> 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
next prev parent reply other threads:[~2013-04-15 22:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-11 22:45 Error with :wrap org in babel and 8.0-pre John Hendy
2013-04-12 22:24 ` Eric Schulte
2013-04-15 17:59 ` John Hendy
2013-04-15 18:12 ` Eric Schulte
2013-04-15 19:35 ` John Hendy
2013-04-15 19:48 ` Andreas Leha
2013-04-15 19:52 ` John Hendy
2013-04-15 19:56 ` Eric Schulte
2013-04-15 19:56 ` Nicolas Goaziou
2013-04-15 20:05 ` John Hendy
2013-04-15 20:15 ` Nicolas Goaziou
2013-04-15 20:28 ` Eric Schulte
2013-04-15 20:51 ` Sebastien Vauban
2013-04-15 21:29 ` John Hendy
2013-04-15 21:44 ` Sebastien Vauban
2013-04-15 21:51 ` John Hendy
2013-04-15 21:24 ` John Hendy
2013-04-15 21:42 ` Sebastien Vauban
2013-04-15 22:38 ` Eric Schulte
2013-04-15 22:48 ` John Hendy [this message]
2013-04-15 23:27 ` Eric Schulte
2013-04-15 23:56 ` Thomas S. Dye
2013-04-16 2:37 ` Eric Schulte
2013-04-16 7:58 ` Sebastien Vauban
2013-04-16 8:23 ` Christian Moe
2013-04-16 14:58 ` John Hendy
2013-04-16 15:24 ` Eric Schulte
2013-04-16 21:06 ` Christian Moe
2013-04-15 20:09 ` Sebastien Vauban
2013-04-15 20:22 ` Nicolas Goaziou
2013-04-15 19:47 ` Sebastien Vauban
2013-04-15 21:38 ` John Hendy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+M2ft_mFPvyn_Jry-D7rVamzOoY+c+ozC=JcZAno=XLu=B6kQ@mail.gmail.com' \
--to=jw.hendy@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
--cc=schulte.eric@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).