Re: [babel][PATCHES] ob-R patches for review

[Rainer M Krug <Rainer@krugs.de>]

[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]

Eric Schulte <schulte.eric@gmail.com> writes:

> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Hi Rainer,
>>>
>>> Rainer M Krug <r.m.krug@gmail.com> writes:
>>>
>>>> I'll look at it again tomorrow and let you know as I made some changes
>>>> since then. Do you prefer one patch to several?
>>>
>>> Up to Eric's taste -- but in general I think a series of patches
>>> is better, it allows you to isolate and fix conflicts more easily.
>>
>
> I agree, multiple patches make future maintenance easier.
>

OK - I'll do so.

A little bit off-topic, is there a "git way" of splitting one patch into
several patches, if it was a single commit?

>>> I missed some previous discussion in this thread.  Are these patches
>>> ready to be applied as is?
>>>
>>
>>
>> IMO, the patches hard coded behaviors that would better be customizable
>> and optional. 
>>
>> Rainer and I had some back and forth about this -- see the thread.
>
> With respect to these points, I'm inclined to agree with Charles in the
> following.

OK - see further comments below.

>
>> All you have to do is add this:
>>
>> (defvar org-babel-R-assign-elisp-function 'org-babel-R-assign-elisp
>>   "Name or definition of function to handle `:var name=value'
>> header args."
>>   )
>>
>> and change one line in org-babel-variable-assignments:R from
>>
>>     (org-babel-R-assign-elisp to
>>
>>    (funcall org-babel-R-assign-elisp-function
>>
>> and the user can provide her own elisp assignment function.
>>
>> This gives users who want special behavior like creating something
>> other than a data.frame the option of providing their own function.
>
> Would such a customization variable be difficult to add to your patches?

I don't think so - I'll look into it.

> If not would you mind submitting a version of the patches split into
> multiple commits with as much of the hard-coded R code as feasible
> placed into customizable variables along the lines of the
> `org-babel-R-assign-elisp-function' variable suggested by Charles.  

I am thinking of actually not providing the R code in org-variables, but
to put them into R files and to source them. By doing this, the
customization could be done in R, which will be much easier for R users
then to customize emacs variables.

These would be sourced and stored into an environment "org:functions",
using the same approach as ESS is using to store functions into an
environment "ESSR". I would then put the variables transfered into
"org:variables". These environments would only exist in the search path,
and not overwrite any user set objects in R.

As it needs to be sourced for each R process once, the right place would
be in  org-babel-R-initiate-session - correct?

What would be the best place to put these R files? 

> One lesson I've certainly learned from the Org-mode mailing list is
> that you can't anticipate all of the ways that your code will be used,
> so up-front customizability generally pays off.

OK - point taken - and I am definitely one of those users who thinks
about unusual usages of certain features.

Cheers,

Rainer

>
> Thanks,
> Eric
>
>>
>> Thanks
>>
>> Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: Type: application/pgp-signature, Size: 494 bytes --]