diff --git a/rorg.org b/rorg.org index 2f1bfe42c..43772f732 100644 --- a/rorg.org +++ b/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