This proposal for code tidying uses multiple-value-bind to satisfy:
1. The various parsed/resolved components of the param list (session,
vars, result-type) are available in the org-babel-execute:LANG
functions.
2. Those functions don't duplicate the code for parsing the params
list and resolving references
3. The functions still have the params list available to them, should
they need to implement language-specific behaviour using it.
If the org-babel-execute:LANG functions need to be called directly,
then that would now have to be via
(multiple-value-bind (session vars result-params result-type)
(org-babel-process-params params) (funcall cmd body params))
as in org-babel-exp.el. (But is it actually necessary to by-pass
org-babel-execute-src-block?)
In order to get new tangle load-file function. Had to resolve org-babel.org conflict manually and didn't know the 'proper' way to do so, so there may be weirdness in that file.
I haven't managed to see why this is a 2. It breaks if cell is a
string of length 1. I'm changing it to a 1 (as it is in
org-collector.el), on the assumption that the 2 was erroneous.
I haven't managed to see why this is a 2. It breaks if cell is a
string of length 1. I'm changing it to a 1 (as it is in
org-collector.el), on the assumption that the 2 was erroneous.
Using symbol instead of string so that assq-delete-all works. This
will break if a variable has a name that is not a valid elisp symbol
-- unlikely? Possible? Also, fixing the argument parsing regexp, which
had been very lazily written.
unified concept of function calls.
Previously LoB calls were not able to produce results in the
buffer. These changes go some way to allowing them to do that. [There
are still some bugs to deal with]. That meant changing org-babel.el so
that there is a notion of the `source block name' for a LoB line, in
order to construct a #+resname (currently I've made the name the same
as the function call).
I'm also slowly moving towards unifying the notion of `function calls'
a bit more: I've changed the org-babel-lob-one-liner-regexp so that
instead of a monolithic match it now matches first the function name,
and second the function arguments in
parentheses. org-babel-lob-get-info makes that match, and although it
still concatenates them and returns the string, the two elements can
be accessed immediately afterwards using match-string. So that
situation is very similar to org-babel-get-src-block-name, whose
job (in this branch) is also to parse the function *name* and the
function *arguments*. In a few places in the code (esp. function
names), I think the word `info' should be replaced with `call' or
`function call', which I believe more accurately indicates what the
`info' is: a function definition, together with bound
arguments/references.
The function call syntax, i.e. function-name(arg1=ref1), originally
introduced for references (and thereby in LoB), and which I'm
proposing we use throughout, raises the question of default arguments,
and those being over-ridden by supplied arguments, as in e.g. python,
and R.
style syntax. There still needs to be work done on the regexps for
recognising #+srcname lines possibly with/without parenthesised
arguments. This change makes org-babel-block-name return nil rather
than fail when it doesn't find a src block head (e.g. in a #+lob
line), which seems sensible.
The sbe test table is failing half-way down at `simple ruby
arrays'. For some reason it is making a mini table ("| |") to the
right hand, and point keeps jumping out of the table. My ability to
debug sbe-related stuff is hampered by me not understanding the
code (I need to learn about macros).
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.
This reverts commit d8001facab.
Going back to original plan of simply passing (cmd body params) to the org-babel-execute:LANG functions.
The benefit of this is that languages will have access to the full params list. A downside is that code parsing the
params list and referencing variables is currently duplicated across the languages, so perhaps we can aim to reduce
that code duplication at some point.
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.
Bug fix: I was missing out org-babel-table-or-string with external
process evaluation (non-session).
Also, I have renamed org-babel-ruby-table-or-results to org-babel-ruby-table-or-string.
(the previous commit's message should have read org-babel-python-table-or-results...)
Dan Davison
Eric Schulte