If `org-edit-special' is called with a prefix argument from inside a
source-code block which has a session, then the session is prepared
according to the header arguments of the source-code blocks.
This is implemented at a `defadvice' because the org-edit-src-hook
is called from inside of the edit buffer, rather than the org
buffer, and it wasn't clear how to access a prefix arg from inside
of the hook.
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.
At some point it might be useful (to me at least) to clarify our rules
regarding whitespace, and make guidelines for using " \t\f\n\v\r" et
al (and [:space:]?).
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.
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?)
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.
Eric Schulte
Dan Davison