emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [babel] return file from R


From: Andreas Leha
Subject: Re: [O] [babel] return file from R
Date: Thu, 17 Dec 2015 22:04:54 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (darwin)

Hi Chuck,

"Charles C. Berry" <address@hidden> writes:
> On Thu, 17 Dec 2015, Andreas Leha wrote:
>
>> Hi all,
>>
>> I think there is a bug in the handling of results of R src blocks.  What
>> is the suggested way to make an R block return a link to a file?  The
>> obvious way appends a newline character to the file link (which is
>> broken because of that).
>>
>> Here is an example:
>> --8<---------------cut here---------------start------------->8---
>> #+NAME: TESTSRC
>> #+BEGIN_SRC R :results file
>>  a <- file.path("junk", "test.org")
>>  a
>> #+END_SRC
>>
>> #+RESULTS: TESTSRC
>> [[file:junk/test.org
>> ]]
>>
>> --8<---------------cut here---------------end--------------->8---
>
>
> That *is* the suggested way, and it will work in (say) emacs-lisp. The
> problem for `:results value' (the default) is that a newline is added
> to the result by `org-babel-R-evaluate-external-process'.

Thanks for the confirmation.

>
> This *might* be the fix, but I do not have time to check it thoroughly:
>
> diff --git a/lisp/ob-R.el b/lisp/ob-R.el
> index f72cd95..f660bbd 100644
> --- a/lisp/ob-R.el
> +++ b/lisp/ob-R.el
> @@ -397,7 +397,7 @@ last statement in BODY, as elisp."
>       (org-babel-result-cond result-params
>         (with-temp-buffer
>           (insert-file-contents tmp-file)
> -         (buffer-string))
> +         (org-babel-chomp (buffer-string) "\n"))
>         (org-babel-import-elisp-from-file tmp-file '(16)))
>       column-names-p)))
>      (output (org-babel-eval org-babel-R-command body))))
>

I'll try to test this in the next days.

>
> In the meanwhile, you can work around by using `:results output' and
> wrapping the result in cat().

Yes.  But usually my source blocks are more noisy and produce some
messages, which would break this approach.

Thanks again,
Andreas




reply via email to

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