'babel'. Added a speculative function which creates a hash table
containing parsed versions of all source blocks in a buffer -- I was
wondering whether we should 'load' the library-of-babel into memory in
this fashion, rather than searching for code blocks in buffers /
files.
srcname, and function org-babel-named-src-block-regexp-for-name
returning regexp matching a block with a particular
name. org-babel-named-src-block-regexp is set by
org-babel-set-interpreters.
I'm now proposing to implement it, at least temporarily, as a
degenerate source block (has no body), with interpreter name
'babel'. These 'babel' blocks will use a :srcname header arg to refer
to the source code block that they will use for their body. This
source code block might be in the 'library of babel'. If so it will
use a conventional variable name for its 'main data argument' such as
__data__. Then the babel block (not to be confused with a code block
in the lob) would use :var __data__=ref, where ref is a resource
reference resolved as usual.
This is intended to provide off-the-shelf data plotting and analysis
functions. Current idea is to introduce a new line, perhaps something
like #+babel or #+babel_lib, which will reference (a) some data
and (b) a source block to apply to the data. Code being stolen from
org-babel.el (conceivably some abstraction of some of those functions
could be done to avoid code duplication).
1) broke reading from #+resname lines
2) shell sometimes stalls indefinitely
3) need condition-case for safe removal of filter when C-g during execution
4) need to add tests for session behavior
- moved ruby functions into their own buffer
- removed org-babel-sessions.el
- drastically scaled down org-babel-comint.el (may grow later if we
find duplication between language buffers)
- removed org-babel-script.el
- adjusted org-babel-init.el to reflect new file layout
For the big breakthrough see `org-babel-ruby-evaluate' in
org-babel-ruby.el. This will be the model upon which all future
language evaluations will be built.