This is a rough, first-pass implementation using some code from
org-babel-ref.el. If we do go with this idea, I think we can find a
better implementation, hopefully using the same code for parsing
`function calls' (parameterised source block calls), whether they are
made directly at a source block, or as a reference in another function
call, or as a LoB call.
Moved reference resolution out of language-specific files; changed
things so that we parse the header args list in org-babel.el, and
changed the argument list of the org-babel-execute:LANG functions
accordingly. In addition to hopefully resulting in easier maintenance,
this results in more streamlined org-babel-execute:LANG functions, and
hence less work to do when adding interpreters.
results-processing changes and state they are currently in. Here's the
comment:
You can see below the various fragments of results-processing
code that were present in the language-specific files. Out of
those fragments, I've moved the
org-babel-python-table-or-results and
org-babel-import-elisp-from-file functionality into the
org-babel-*-evaluate functions. I think those should only be
used in the :results value case, as in the 'output case we are
not concerned with creating elisp versions of results.
The rest of the functionality below, concerned with vectorising
or scalarising results is commented out, has not yet been
replaced, and may need to be reinstated in this function
This reverts commit a13cbf64b6.
I'm in favour of this change, but it seems that we need a more sophisticated way of combining plists before we can
change the default header args in this way. Otherwise, we get two entries for :results (one from the defaults and one
from the header args), whereas what we want is a single entry for :results with space-separated values.
When :results is 'value, the org-babel-LANG-evaluate functions are
responsible for returning an elisp representation of the *value* of
the block. This stage is maintained in the language-specific code
because different languages have different ways of doing it: python
and ruby use org-babel-LANG-table-or-string, whereas R and shell write
to file and then use org-babel-import-elisp-from-file. It could
however be put in the org-babel-execute:LANG function.
Results processing code has been moved out of language-specific
files (which all contained similar versions of essentially the same
code) and into the central org-babel.el. This commit maintains the
removed language-specific fragments commented out in org-babel.el. It
does not make an attempt to replace their functionality (the new
function org-babel-process-result currently does nothing).
Similarly, I intend to move the reference resolution code out of
language-specific 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.
Dan Davison
Eric Schulte