[O] [PATCH] :wrap header documentation

2012-01-11 Thread Thomas S. Dye
Hi Eric,

Attached please find a first draft of a patch for the manual entry
documenting a :wrap header argument.

All the best,
Tom

From 4e3a66a4fbfd8d6914fbfd3924981ae5c526aa4a Mon Sep 17 00:00:00 2001
From: Thomas Dye d...@poto.myhome.westell.com
Date: Wed, 11 Jan 2012 16:06:17 -1000
Subject: [PATCH] * doc/org.texi: added documentation for :wrap

---
 doc/org.texi |   12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/doc/org.texi b/doc/org.texi
index f619c90..7ca797b 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -715,6 +715,7 @@ Specific header arguments
 * rownames::Handle row names in tables
 * shebang:: Make tangled files executable
 * eval::Limit evaluation of specific code blocks
+* wrap::Mark source block evaluation results
 
 Miscellaneous
 
@@ -13007,6 +13008,7 @@ argument in lowercase letters.  The following header arguments are defined:
 * rownames::Handle row names in tables
 * shebang:: Make tangled files executable
 * eval::Limit evaluation of specific code blocks
+* wrap::Mark source block evaluation results
 @end menu
 
 Additional header arguments are defined on a language-specific basis, see
@@ -13865,7 +13867,7 @@ Setting the @code{:shebang} header argument to a string value
 first line of any tangled file holding the code block, and the file
 permissions of the tangled file are set to make it executable.
 
-@node eval,  , shebang, Specific header arguments
+@node eval, wrap, shebang, Specific header arguments
 @subsubsection @code{:eval}
 The @code{:eval} header argument can be used to limit the evaluation of
 specific code blocks.  The @code{:eval} header argument can be useful for
@@ -13890,6 +13892,14 @@ If this header argument is not set then evaluation is determined by the value
 of the @code{org-confirm-babel-evaluate} variable see @ref{Code evaluation
 security}.
 
+@node wrap, , eval, Specific header arguments
+@subsubsection @code{:wrap}
+The @code{:wrap} header argument is used to mark the results of source block
+evaluation.  The header argument can be passed a string that typically will
+be appended to @code{#+BEGIN_} and @code{#+END_}, which will then be used to
+wrap the results.  An exception to this rule is the string @code{drawer},
+which instead wraps the results in an Org mode drawer.
+
 @node Results of evaluation, Noweb reference syntax, Header arguments, Working With Source Code
 @section Results of evaluation
 @cindex code block, results of evaluation
-- 
1.7.5.4


t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

-- 
Thomas S. Dye
http://www.tsdye.com


Re: [O] [PATCH] :wrap header documentation

2012-01-11 Thread Eric Schulte
Hi Tom,

Thanks for this patch, I've just pushed up an augmented version which
more closely matches the current behavior.

t...@tsdye.com (Thomas S. Dye) writes:

 Hi Eric,

 Attached please find a first draft of a patch for the manual entry
 documenting a :wrap header argument.

 All the best,
 Tom



 t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/



Re: [O] [PATCH] :wrap header documentation

2012-01-11 Thread Thomas S. Dye
Hi Eric,

It's great to find :wrap in master.  Thanks for augmenting the draft.

All the best,
Tom

Eric Schulte eric.schu...@gmx.com writes:

 Hi Tom,

 Thanks for this patch, I've just pushed up an augmented version which
 more closely matches the current behavior.

 t...@tsdye.com (Thomas S. Dye) writes:

 Hi Eric,

 Attached please find a first draft of a patch for the manual entry
 documenting a :wrap header argument.

 All the best,
 Tom



 t...@tsdye.com (Thomas S. Dye) writes:

 Eric Schulte eric.schu...@gmx.com writes:

 Achim Gratz strom...@nexgo.de writes:

 t...@tsdye.com (Thomas S. Dye) writes:
 The attached patch defines a new header argument, :special, which wraps
 the results of Org babel source block execution in a #BEGIN_ ... #+END_
 block.  The block name is taken from a new variable
 org-babel-wrap-special, which is initialized as results.

 What is the rationale for feeding the block name via a configuration
 variable rather then a value to the header argument :special?


 Regards,
 Achim.

 Attached is an alternate patch and an example of its use.  This patch
 introduces a :wrap header argument which accepts an optional value
 used to specify the name of the block with which to wrap results.  If
 this looks workable we could push it up once it gets some documentation
 and tests.

 Cheers,


 #+Title: demonstrating the new :wrap header argument

 #+begin_src emacs-lisp :wrap schulte
   '((1 2)
 (3 4))
 #+end_src

 #+results:
 #+BEGIN_schulte
 | 1 | 2 |
 | 3 | 4 |
 #+END_schulte

 Hi Eric,

 Thanks for the :wrap header argument.  It works for me.

 The attached patch on top of your patch looks for :wrap drawer, and puts
 the result in a drawer, rather than wrapping the results in #+begin
 ... #+end.

 What I'm trying to do is make :results wrap obsolete.

 Also, note that with the :wrap header argument, :results org and
 :results latex are both redundant.  I'm not sure how you want to handle
 this--whether to leave them in place or remove them.

 I'll volunteer to work on the documentation.

 All the best,
 Tom

-- 
Thomas S. Dye
http://www.tsdye.com