[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rainer M Krug
Subject: Re: [O] [babel][PATCHES] ob-R patches for review
Date: Mon, 12 May 2014 10:33:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (darwin)

Eric Schulte <address@hidden> writes:

> Rainer M Krug <address@hidden> writes:
>> Bastien <address@hidden> writes:
>>> Hi Rainer,
>>> Rainer M Krug <address@hidden> 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.



> 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:      address@hidden

Skype:      RMkrug

PGP: 0x0F52F982

Attachment: pgp2qYXMHqUvZ.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]