mirrors/org-mode
0
0
Fork 1
mirror of https://git.savannah.gnu.org/git/emacs/org-mode.git synced 2024-07-15 17:16:26 +00:00
Code Releases Activity

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

Browse source 
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.
This commit is contained in:
Eric Schulte 2009-05-20 17:51:35 -07:00
parent 2cc09a2029
commit 3a0be8fd06
1 changed files with 60 additions and 58 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

118
rorg.org
View file

@ -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