emacs-orgmode
[Top][All Lists]
Advanced

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

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


From: Eric Schulte
Subject: Re: [O] [babel][PATCHES] ob-R patches for review
Date: Mon, 12 May 2014 09:21:09 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

>> 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.
>

I think this is a bad idea, such external R source files may be hard to
manage and load reliably across systems and it is not clear where they
should live in the Org-mode repository.  Additionally, if the variables
simply hold R code text, then users can easily initialize them from R
files locally with something like the following.

    (setq org-babel-R-assign-elisp-function
          (with-temp-buffer
            (insert-file-contents-literally "personal.R")
            (buffer-string)))

I think this approach is much simpler.

Best,
Eric

>
> 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

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D



reply via email to

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