From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: import R data frame into org-mode table Date: Mon, 29 Jul 2013 13:11:47 -0400 Message-ID: <87ehahb8a4.fsf@gmail.com> References: <87mwpket4b.fsf@med.uni-goettingen.de> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3qzV-0005V9-GY for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 13:12:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V3qzP-0002Tm-Lc for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 13:12:13 -0400 Received: from plane.gmane.org ([80.91.229.3]:53437) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V3qzP-0002TY-El for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 13:12:07 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V3qzI-0000qM-CL for emacs-orgmode@gnu.org; Mon, 29 Jul 2013 19:12:00 +0200 Received: from pool-108-7-96-134.bstnma.fios.verizon.net ([108.7.96.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jul 2013 19:12:00 +0200 Received: from ndokos by pool-108-7-96-134.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Jul 2013 19:12:00 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org John Hendy writes: > On Mon, Jul 29, 2013 at 10:35 AM, Cook, Malcolm wrote: >>>Hi Andreas, >> > >> >On 17 July 2013 23:09, Andreas Leha wrote: >> > >> >> Definitely there is: >> >> >> >> --8<---------------cut here---------------start------------->8--- >> >> #+begin_src R :results table :colnames yes >> >> read.csv('test.csv') >> >> #+end_src >> >> >> >> #+results: >> >> | X | Variant | Xaxis | N | mean | sd | se | >> >> |---+---------+-------+---+--------+------+------| >> >> | 1 | line1 | 10 | 5 | 111.11 | 9.33 | 3.11 | >> >> | 1 | line1 | 20 | 5 | 112.11 | 9.13 | 3.14 | >> >> | 1 | line1 | 30 | 5 | 113.11 | 9.43 | 3.1 | >> >> | 1 | line2 | 10 | 5 | 101.11 | 8.33 | 2.11 | >> >> | 1 | line2 | 20 | 5 | 100.11 | 8.13 | 2.12 | >> >> | 1 | line2 | 30 | 5 | 108.11 | 8.03 | 2.1 | >> >> >> >> --8<---------------cut here---------------end--------------->8--- >> > >> >Great. I've gone ahead and done this. There are two additional requirements: >> >1) My table needs a caption. Will #+CAPTION: just above the >> >#+BEGIN_SRC just work? >> >> Yes I don't think so: the caption is a property of the table, not of the code block, so putting it before the code block does not work (at least in my limited 8.x tests). You have to put it before the table - see example below. >> >>> Even better, a label, allowing me to also cross >> >reference it. >> >2) My table is too long for 1 page. It spans multiple pages >> >vertically. According to this StackOverflow answer >> >http://stackoverflow.com/a/2896850/1526266 , I should instead use >> >longtable, not tabular. Is there a way to coerce your above snippet to >> >use longtable, instead of tabular which is the default. >> > >> >> Looks like your answer is here: http://orgmode.org/manual/Tables-in-LaTeX-export.html > > Sort of. Depends on the Org-mode version, and someone will have to > chime in on the updated status of various parts of the manual. For 8+, > I believe the syntax is different: > > #+attr_latex: :environment longtable > > Also, there have been many threads in the past about how to add > #+attr_latex lines to results output (mostly graphics/files) > successfully. If you simply take the above and add =#+attr_latex: > stuff= above the =#+results= line, babel won't recognize it and will > just create a new results block. If those on this email are already > well aware of this... my apologies for being redundant, but it causes > enough confusion that I figured I'd leave another bread crumb trail :) > Here's an example of a time that came up on the list: > - http://lists.gnu.org/archive/html/emacs-orgmode/2012-07/msg00237.html > This is no longer the case: Eric S. fixed this a couple of months ago, so that even an unlabeled #+RESULTS block will get the recomputed results without creating a new block. The following exports fine to latex/pdf with current org: --8<---------------cut here---------------start------------->8--- * foo #+begin_src R :results table :colnames yes :exports results read.csv('test.csv') #+end_src #+NAME: foo #+CAPTION: My table #+ATTR_LATEX: :environment longtable #+RESULTS: | X | Variant | Xaxis | N | mean | sd | se | |---+---------+-------+---+--------+------+------| | 1 | line1 | 10 | 5 | 111.11 | 9.33 | 3.11 | | 1 | line1 | 20 | 5 | 112.11 | 9.13 | 3.14 | | 1 | line1 | 30 | 5 | 113.11 | 9.43 | 3.1 | | 1 | line2 | 10 | 5 | 101.11 | 8.33 | 2.11 | | 1 | line2 | 20 | 5 | 100.11 | 8.13 | 2.12 | | 1 | line2 | 30 | 5 | 108.11 | 8.03 | 2.1 | * bar See Table \ref{foo}. --8<---------------cut here---------------end--------------->8--- even satisfying the OP's desire for labeling the table so that the xref will work (although there may be better methods to xref: I haven't kept up with the recent discussions on the ML). Of course, naming the code block should still be considered best practice IMO. -- Nick