combined all "running processes" TODOs and bumped down to DEFERRED

  While these are good ideas they represent a big chunk of work which
  will break everything while it's being done, should wait for now.

rorg.org

@@ -1,9 +1,9 @@
 #+OPTIONS:    H:3 num:nil toc:t
 #+TITLE: rorg --- Code evaluation in org-mode, with an emphasis on R
-#+SEQ_TODO:  TODO OPEN PROPOSED | DONE DEFERRED REJECTED
+#+SEQ_TODO:  TODO PROPOSED | DONE DEFERRED REJECTED
 #+STARTUP: oddeven
 
-* Tasks [11/20]
+* Tasks [12/18]
 ** TODO results-type header (scalar/vector)
 In response to a point in Dan's email.  We should allow the user to
 force scalar or vector results.  This could be done with a header
@@ -102,62 +102,6 @@ source code block.
 I think the best way to approach this would be to start with an
 example R source-code block and then work up from there.
 
-** TODO ability to select which of multiple sessions is being used
-   Increasingly it is looking like we're going to want to run all
-   source code blocks in comint buffer (sessions).  Which will have
-   the benefits of
-   1) allowing background execution
-   2) maintaining state between source-blocks
-      - allowing inline blocks w/o header arguments 
-
-*** R sessions
-    (like ess-switch-process in .R buffers)
-    
-    Maybe this could be packaged into a header argument, something
-    like =:R_session= which could accept either the name of the
-    session to use, or the string =prompt=, in which case we could use
-    the =ess-switch-process= command to select a new process.
-    
-** TODO evaluation of shell code as background process? 
-   After C-c C-c on an R code block, the process may appear to
-   block, but C-g can be used to reclaim control of the .org buffer,
-   without interrupting the R evalution. However I believe this is not
-   true of bash/sh evaluation. [Haven't tried other languages] Perhaps
-   a solution is just to background the individual shell commands.
-
-   The other languages (aside from emacs lisp) are run through the
-   shell, so if we find a shell solution it should work for them as
-   well.
-   
-   Adding an ampersand seems to be a supported way to run commands in
-   the background (see [[http://www.emacswiki.org/emacs/ExecuteExternalCommand#toc4][external-commands]]).  Although a more extensible
-   solution may involve the use of the [[elisp:(progn (describe-function 'call-process-region) nil)][call-process-region]] function.
-   
-   Going to try this out in a new file [[file:litorgy/litorgy-proc.el][litorgy-proc.el]].  This should
-   contain functions for asynchronously running generic shell commands
-   in the background, and then returning their input.
-
-*** partial update of org-mode buffer
-   The sleekest solution to this may be using a comint buffer, and
-   then defining a filter function which would incrementally interpret
-   the results as they are returned, including insertion into the
-   org-mode buffer.  This may actually cause more problems than it is
-   worth, what with the complexities of identifying the types of
-   incrementally returned results, and the need for maintenance of a
-   process marker in the org buffer.
-
-*** 'working' spinner
-    It may be nice and not too difficult to place a spinner on/near the
-    evaluating source code block
-
-** TODO conversion of output from interactive shell, R (and python) sessions to litorgy buffers
-   [DED] This would be a nice feature I think. Although a litorgy purist
-   would say that it's working the wrong way round... After some
-   interactive work in a *R* buffer, you save the buffer, maybe edit
-   out some lines, and then convert it to litorgy format for
-   posterity. Same for a shell session either in a *shell* buffer, or
-   pasted from another terminal emulator. And python of course.
-
 ** 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
@@ -201,6 +145,63 @@ for quick tests
 mean(mean(vec))
 #+end_src
 
+** DEFERRED Rework Interaction with Running Processes [0/3]
+*** TODO ability to select which of multiple sessions is being used
+    Increasingly it is looking like we're going to want to run all
+    source code blocks in comint buffer (sessions).  Which will have
+    the benefits of
+    1) allowing background execution
+    2) maintaining state between source-blocks
+       - allowing inline blocks w/o header arguments 
+
+**** R sessions
+     (like ess-switch-process in .R buffers)
+     
+     Maybe this could be packaged into a header argument, something
+     like =:R_session= which could accept either the name of the
+     session to use, or the string =prompt=, in which case we could use
+     the =ess-switch-process= command to select a new process.
+     
+*** TODO evaluation of shell code as background process? 
+    After C-c C-c on an R code block, the process may appear to
+    block, but C-g can be used to reclaim control of the .org buffer,
+    without interrupting the R evalution. However I believe this is not
+    true of bash/sh evaluation. [Haven't tried other languages] Perhaps
+    a solution is just to background the individual shell commands.
+
+    The other languages (aside from emacs lisp) are run through the
+    shell, so if we find a shell solution it should work for them as
+    well.
+    
+    Adding an ampersand seems to be a supported way to run commands in
+    the background (see [[http://www.emacswiki.org/emacs/ExecuteExternalCommand#toc4][external-commands]]).  Although a more extensible
+    solution may involve the use of the [[elisp:(progn (describe-function 'call-process-region) nil)][call-process-region]] function.
+    
+    Going to try this out in a new file [[file:litorgy/litorgy-proc.el][litorgy-proc.el]].  This should
+    contain functions for asynchronously running generic shell commands
+    in the background, and then returning their input.
+
+**** partial update of org-mode buffer
+    The sleekest solution to this may be using a comint buffer, and
+    then defining a filter function which would incrementally interpret
+    the results as they are returned, including insertion into the
+    org-mode buffer.  This may actually cause more problems than it is
+    worth, what with the complexities of identifying the types of
+    incrementally returned results, and the need for maintenance of a
+    process marker in the org buffer.
+
+**** 'working' spinner
+     It may be nice and not too difficult to place a spinner on/near the
+     evaluating source code block
+
+*** TODO conversion of output from interactive shell, R (and python) sessions to litorgy buffers
+    [DED] This would be a nice feature I think. Although a litorgy purist
+    would say that it's working the wrong way round... After some
+    interactive work in a *R* buffer, you save the buffer, maybe edit
+    out some lines, and then convert it to litorgy format for
+    posterity. Same for a shell session either in a *shell* buffer, or
+    pasted from another terminal emulator. And python of course.
+
 ** DONE litorgy tests litorgy [1/1]
 since we are accumulating this nice collection of source-code blocks
 in the sandbox section we should make use of them as unit tests.
@@ -379,6 +380,7 @@ This is currently working only with emacs lisp as in the following
 example in the [[* emacs lisp source reference][emacs lisp source reference]].
 
 
+
 * Bugs [6/8]
 
 ** TODO cursor movement when evaluating source blocks