brought in org-babel.org changes from master

org-babel.org

@@ -587,9 +587,16 @@ echo $other ' is the old date'
 #+resname: task-call-other-shell
 : $ Fri Jun 12 13:08:37 PDT 2009  is the old date
 
-*** TODO implement a *session* header argument
+*** TODO implement a *session* header argument [0/4]
+=:session= header argument to override the default *session* buffer
 
-use this header argument to override the default *session* buffer
+**** TODO R
+
+
+
+**** TODO ruby
+**** TODO python
+**** TODO shell
 
 *** TODO function to bring up inferior-process buffer
 
@@ -753,14 +760,18 @@ $0
 
 waiting for guidance from those more familiar with yasnippets
 
-** TODO resolve references to other buffers
+** TODO resolve references to other org buffers/files
    This would allow source blocks to call upon tables, source-blocks,
-   and results in other buffers.
+   and results in other org buffers/files.
    
    See...
    - [[file:lisp/org-babel-ref.el::TODO%20allow%20searching%20for%20names%20in%20other%20buffers][org-babel-ref.el:searching-in-other-buffers]]
    - [[file:lisp/org-babel.el::defun%20org-babel%20find%20named%20result%20name][org-babel.el#org-babel-find-named-result]]
-
+** TODO resolve references to other non-org files
+   - tabular data in .csv, .tsv etc format
+   - files of interpreted code: anything stopping us giving such files
+     similar status to a source code block?
+   - Would be nice to allow org and non-org files to be remote
 ** TODO figure out how to handle errors during evaluation
    R has a try function, with error handling, along the lines of
    python. I bet ruby does too. Maybe more of an issue for functional
@@ -776,6 +787,68 @@ results in the buffer.  Then if there is a combination of =silent= and
 =file= =:results= headers we could drop the results to a temp buffer
 and pop open that buffer...
 
+** TODO Finalise behaviour regarding vector/scalar output
+*** DONE Stop spaces causing vector output
+This simple example of multilingual chaining produces vector output if
+there are spaces in the message and scalar otherwise.
+
+[Not any more]
+
+#+begin_src R :var msg=msg-from-python
+paste(msg, "und R", sep=" ")
+#+end_src
+
+#+resname:
+: org-babel speaks elisp y python und R
+
+#+srcname: msg-from-python
+#+begin_src python :var msg=msg-from-elisp
+msg + " y python"
+#+end_src
+
+#+srcname: msg-from-elisp
+#+begin_src emacs-lisp :var msg="org-babel speaks"
+(concat msg " elisp")
+#+end_src
+
+** TODO re-implement helper functions from org-R
+*** Initial statement [Eric]
+    Much of the power of org-R seems to be in it's helper functions for
+    the quick graphing of tables.  Should we try to re-implement these
+    functions on top of org-babel?
+
+    I'm thinking this may be useful both to add features to org-babel-R and
+    also to potentially suggest extensions of the framework.  For example
+    one that comes to mind is the ability to treat a source-code block
+    like a function which accepts arguments and returns results. Actually
+    this can be it's own TODO (see [[* source blocks as functions][source blocks as functions]]).
+*** Objectives
+    - We want to provide convenient off-the-shelf actions
+      (e.g. plotting data) that make use of our new code evaluation
+      environment but do not require any actual coding.
+*** Design proposal
+    - *Input data* will be specified using the same mechanism as :var
+      references, thus the input data may come from a table, or
+      another source block, and it is initially available as an elisp
+      data structure.
+    - We introduce a new #+ line, e.g.  #+BABELDO. C-c C-c on that
+      line will apply an *action* to the referenced data.
+    - *Actions correspond to source blocks*: our library of available
+      actions will be a library of org-babel source blocks. Thus the
+      code for executing an action, and the code for dealing with the
+      output of the action will be the same code as for executing
+      source blocks in general
+    - Optionally, the user can have the relevant source block inserted
+      into the org buffer after the (say) #+BABELDO line. This will
+      allow the user to fine tune the action by modifying the code
+      (especially useful for plots).
+    - So maybe a #+BABELDO line will have header args
+      - :data (a reference to a table or source code block)
+      - :action (or should that be :srcname?) which will be something
+        like :action pie-chart, referring to a source block which will
+        be executed with the :data referent passed in using a :var arg.
+      - :showcode or something controlling whether to show the code
+      
 ** TODO share org-babel
 how should we share org-babel?
 
@@ -1007,17 +1080,6 @@ This would allow for display of images upon export providing
 functionality similar to =org-exp-blocks= only in a more general
 manner.
 
-** PROPOSED re-implement helper functions from org-R
-Much of the power of org-R seems to be in it's helper functions for
-the quick graphing of tables.  Should we try to re-implement these
-functions on top of org-babel?
-
-I'm thinking this may be useful both to add features to org-babel-R and
-also to potentially suggest extensions of the framework.  For example
-one that comes to mind is the ability to treat a source-code block
-like a function which accepts arguments and returns results. Actually
-this can be it's own TODO (see [[* source blocks as functions][source blocks as functions]]).
-
 ** DEFERRED use textConnection to pass tsv to R?
    When passing args from the org buffer to R, the following route is
    used: arg in buffer -> elisp -> tsv on file -> data frame in R. I