With this change we avoid messing about extracting the output from the
comint buffer in the :results value case (the value has already been
written to file).
I don't believe this solves it, but chomp is more the right thing to
do than trim. I'd like to retain all the whitespace so that alignment
of columns is correct in stdout.
Unlike the other languages, it's central to R to be able to index
columns of a data frame d, either by d[,"columnname"] of d$columnname.
With this change, if colnames are present in the *input* from
org-babel, the corresponding R variable is *always* constructed with
the colnames.
In addition, with the :colnames header arg, the *output* to elisp/org
buffer contains the colnames separated from the rest of the table by
'hline. This behaviour is not default because other languages may
expect a simple table without the 'hline.
THis brings in the bugfix from 4f15280631, as well as gnuplot. The bugfix required manual resolution as it had already been partially addressed in this branch. Also, the interaction of the possibility of being on a #+lob line and the possiblity of being in the middle of an org-babel-exp-results call, meant I had to rearrange things a bit, so this commit has new changes in org-babel-where-is-src-block-result in addition to the merge.
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?)
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.
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...)
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.
