From: "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
Subject: Re: Two modifications for source blocks processing (will be in 7.9.2)
Date: Wed, 26 Sep 2012 22:20:08 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
A (very) quick answer...
Thomas S. Dye wrote:
> Sebastien Vauban writes:
>> Bastien wrote:
>>> this is to advertize two small modifications wrt source blocks
>>> 1) Please use ":results drawer" instead of ":results wrap" to insert
>>> results like this:
>>> #+BEGIN_SRC emacs-lisp :results drawer
>>> (message "a")
>> OK. That name is clearly better!
>>> 2) Support for ":results org" has been removed.
>> Why don't we have anymore "#+begin/end_org" blocks while we still have
>> "#+begin_html" and "#+begin_LaTeX" blocks? Org as the language seemed normal
>> to insert blocks in Org-syntax.
>> How will Org constructs be supported, for example headlines in the old
>> "#+begin/end_org" blocks -- with the "," used for protecting the export?
>> #+begin_src org
>> ,* This is an headline
>> ,This is some text.
>>> You can either insert the results with ":results raw" or "results drawer"
>>> if you need to tell the exporter to include/exclude the results (by
>>> including/excluding the :RESULTS: drawer from export.)
>> Will ":RESULTS:" drawers be included by default, to mimic the current support
>> of "#+begin/end_org" blocks?
> :results org was a synonym for :results raw
With :results raw, the raw output is inserted directly into the Org mode
buffer. This is a good option if your code block will output *Org mode
formatted text* (this will even be fontified as Org text you would have typed
As there are *no obvious markers to delimit the results* in the Org mode file,
there is no way to know where raw results begin or end: raw results *cannot be
removed* from the buffer.
With :results org, raw Org mode results will be harmlessly *wrapped in a Org
mode block*. The "#+begin/end_org" block wrapper makes it possible for the
entirety of the results to be clearly located and replaced upon code block
> so I think "small change" here probably means that support for the synonym
> was dropped.
Hence, not a synonym.
> #+begin/end_org blocks should still work with the :wrap header argument,
> which hasn't been altered, IIUC.
- "wrap" will disappear (renamed as "drawer"),
- "drawer" is not the same as the old "org" option (as the results gets
inserted into a drawer, not into a block).
next prev parent reply other threads:[~2012-09-26 20:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-26 7:44 Bastien
2012-09-26 8:17 ` Sebastien Vauban
2012-09-26 9:09 ` Bastien
[not found] ` <1348655499.WXHGMQZGWMUF@spammotel.com>
2012-09-26 11:06 ` Bastien
2012-09-26 11:57 ` Nicolas Goaziou
2012-09-26 16:28 ` Thomas S. Dye
2012-09-26 20:20 ` Sebastien Vauban [this message]
2012-09-26 20:47 ` Thomas S. Dye
2012-09-26 20:51 ` Eric Schulte
2012-09-26 21:54 ` Bastien
2012-09-27 23:28 ` Thomas S. Dye
2012-09-27 5:34 ` Achim Gratz
2012-09-27 8:07 ` Bastien
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).