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