The o-b-insert-result code was assuming that we were in a source
block, where it could find the head, etc. However there are two
situations when this is not true LoB calls (although they can't output
results to buffer in this branch, they can in branch 'results'), and
org-babel-exp (which calls o-b-insert-result in an empty temp buffer).
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...)
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.
Move org-babel-python-table-or-results into the :results value branch
of org-babel-python-evaluate, and get rid of default case (result-type
must always be either output or value). I wonder if the org-babel-trim
s are necessary: they don't seem to be needed in the code for ruby.
(1) Shell evaluation is broken by weird escape chars in prompt;
(2) ruby evaluation not working for me as run-ruby expects one argument on my system.
Also fixed a harmless copy-paste error and whitespace adjustment to shorten lines.
'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).
