I turns out the problem here is that the table was being parsed for
column headers twice, so the top two rows were both being taken as
column headers. I've just pushed up a fix.
Best -- Eric
Nick Dokos nicholas.do...@hp.com writes:
Thomas S. Dye t...@tsdye.com wrote:
Nick Dokos
Eric Schulte schulte.e...@gmail.com wrote:
I turns out the problem here is that the table was being parsed for
column headers twice, so the top two rows were both being taken as
column headers. I've just pushed up a fix.
Works fine - thanks!
Best -- Eric
Nick Dokos
Thomas S. Dye t...@tsdye.com wrote:
Nick Dokos nicholas.do...@hp.com writes:
While testing my response to Viktor's question, I ran into a problem.
I used a test file that is slightly modified from a previous post of Tom
Dye's:
* R tables
#+TBLNAME: tbl-1
| column1 | column2 |
Nick Dokos nicholas.do...@hp.com writes:
While testing my response to Viktor's question, I ran into a problem.
I used a test file that is slightly modified from a previous post of Tom
Dye's:
* R tables
#+TBLNAME: tbl-1
| column1 | column2 |
|-+-|
| 45 | 34 |
Thomas S. Dye t...@tsdye.com wrote:
Aloha Nick,
I see the same behavior.
Thanks for confirming!
I'm not entirely sure but it seems to be R-specific: when babel does
variable assignments in org-babel-R-assign-elisp, it creates temp files
/tmp/babel-XXX/R-import-YYY and when the tables
Nick Dokos nicholas.do...@hp.com wrote:
Thomas S. Dye t...@tsdye.com wrote:
Aloha Nick,
I see the same behavior.
Thanks for confirming!
I'm not entirely sure but it seems to be R-specific: when babel does
variable assignments in org-babel-R-assign-elisp, it creates temp
While testing my response to Viktor's question, I ran into a problem.
I used a test file that is slightly modified from a previous post of Tom Dye's:
--8---cut here---start-8---
* R tables
#+TBLNAME: tbl-1
| column1 | column2 |
|-+-|
| 45
