[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [org-babel R] Difference between output in RStudio and in Org Ba
From: |
Aaron Ecay |
Subject: |
Re: [O] [org-babel R] Difference between output in RStudio and in Org Babel |
Date: |
Wed, 10 Dec 2014 16:36:18 -0500 |
User-agent: |
Notmuch/0.18.1+51~gbbbdf04 (http://notmuchmail.org) Emacs/25.0.50.2 (x86_64-unknown-linux-gnu) |
Hi Seb,
[re-adding the list to cc]
2014ko abenudak 10an, Sebastien Vauban-ek idatzi zuen:
>
> FYI, the link is a screen capture image, in this case, not a video!
OK, now I feel sheepish. I assumed from the screencast.com URL that
there was intended to be some video, for which the image displayed was
just the (first/last/etc.) frame. Now I understand better.
> With my example, what I expect is:
>
> | | liste | nb |
> |-----+----------------+----|
> | abc | item31\nitem80 | 2 |
> | def | item52 | 1 |
There’s no convention in org tables that “\n” (i.e. two characters,
backslash + n) means newline (i.e. one character).
> In this case, I'd expect the same as in RStudio; that is, no multi-line
> cell, but simply a cell with a string in it -- which, yes, does contain
> the \n character:
What R’s console shows you (either RStudio or vanilla R) is a “human
readable” representation of the data frame, which includes doing
things like changing the newline character into a \n escape sequence
(and other stuff, like padding the columns with spaces so they all
line up vertically). But when Org communicates with R, it asks for a
machine-readable version, which doesn’t include such niceties. When
that machine-readable version includes a newline character in a data
field (as your example table does), org doesn’t know what to do and
messes up.
--
Aaron Ecay