From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Leha Subject: Re: BUG variable expansion with table Date: Fri, 27 Jun 2014 00:25:59 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0J3Y-0002o6-NW for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 19:26:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0J3T-0002qF-5N for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 19:26:16 -0400 Received: from plane.gmane.org ([80.91.229.3]:58956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0J3S-0002q7-Vz for emacs-orgmode@gnu.org; Thu, 26 Jun 2014 19:26:11 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1X0J3R-0006Sb-8G for emacs-orgmode@gnu.org; Fri, 27 Jun 2014 01:26:09 +0200 Received: from cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net ([81.102.136.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jun 2014 01:26:09 +0200 Received: from andreas.leha by cpc33-cmbg15-2-0-cust4.5-4.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 27 Jun 2014 01:26:09 +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 Hi Rainer, Rainer M Krug writes: > Hi > > there seems to be a bug in the table transfer. The org file below > evaluates as shown, i.e. the TABLE_BLOCK contains one column less then > it should as the first column is discarded and the second one used as > the row names. This only occurs when there is a second variable > defined. When the second variable is not passed, the code works (see > second example below). > > I did not get far when debugging, only that in the function > org-babel-R-assign-elisp when assigning TABLE_FILE the rownames are > missing in the =value=. > > Rainer > > First example: > > #+PROPERTY: rownames yes > #+PROPERTY: colnames yes > > #+NAME: TABLE > | | name | description | > |----------+--------------+--------------------| > | annee | year | Year of simulation | > | id | ipoints_Qdiv | Point Number | > | iespece | species | species number | > | scenario | scenario | Type of forest | > #+PROPERTY: var TABLE_FILE=TABLE > #+PROPERTY: var+ float=123.45 > > * Data Assessment Results > #+HEADERS: :var TABLE_BLOCK=TABLE > #+HEADERS: :rownames yes > #+HEADERS: :colnames yes > #+begin_src R :results output wrap > TABLE_FILE > TABLE_BLOCK > #+end_src > > #+RESULTS: > :RESULTS: > name description > annee year Year of simulation > id ipoints_Qdiv Point Number > iespece species species number > scenario scenario Type of forest > Year.of.simulation > ipoints_Qdiv Point Number > species species number > scenario Type of forest > :END: > > > Second example: > > #+PROPERTY: rownames yes > #+PROPERTY: colnames yes > > #+NAME: TABLE > | | name | description | > |----------+--------------+--------------------| > | annee | year | Year of simulation | > | id | ipoints_Qdiv | Point Number | > | iespece | species | species number | > | scenario | scenario | Type of forest | > #+PROPERTY: var TABLE_FILE=TABLE > #+ PROPERTY: var+ float=123.45 > > * Data Assessment Results > #+HEADERS: :var TABLE_BLOCK=TABLE > #+HEADERS: :rownames yes > #+HEADERS: :colnames yes > #+begin_src R :results output wrap > TABLE_FILE > TABLE_BLOCK > #+end_src > > #+RESULTS: > :RESULTS: > name description > annee year Year of simulation > id ipoints_Qdiv Point Number > iespece species species number > scenario scenario Type of forest > name description > annee year Year of simulation > id ipoints_Qdiv Point Number > iespece species species number > scenario scenario Type of forest > :END: FWIW, I think that bug was reported some while back [fn:1] -- unfortunately without a fix .... ;-) - Andreas Footnotes: [fn:1] http://article.gmane.org/gmane.emacs.orgmode/82295/match=