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.
