From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: graphing from org-tables Date: Thu, 22 Jan 2009 17:37:19 -0800 Message-ID: <87y6x2ssz4.fsf@gmail.com> References: <74FDB779-BB93-414F-ABD3-DBA6DE6C528E@gmail.com> <87r640p2ld.fsf@gmail.com> <20090122162711.GA11250@stats.ox.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LQAyb-0002K8-O2 for emacs-orgmode@gnu.org; Thu, 22 Jan 2009 20:36:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LQAya-0002JY-2v for emacs-orgmode@gnu.org; Thu, 22 Jan 2009 20:36:53 -0500 Received: from [199.232.76.173] (port=37634 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LQAyZ-0002JS-Np for emacs-orgmode@gnu.org; Thu, 22 Jan 2009 20:36:51 -0500 Received: from rv-out-0506.google.com ([209.85.198.238]:61674) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LQAyZ-0007h0-93 for emacs-orgmode@gnu.org; Thu, 22 Jan 2009 20:36:51 -0500 Received: by rv-out-0506.google.com with SMTP id f9so183170rvb.2 for ; Thu, 22 Jan 2009 17:36:49 -0800 (PST) In-Reply-To: <20090122162711.GA11250@stats.ox.ac.uk> (Dan Davison's message of "Thu, 22 Jan 2009 11:27:11 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Dan Davison writes: > On Mon, Dec 22, 2008 at 12:00:14PM -0500, Eric Schulte wrote: >> Hi Dan, >> > > <...> > >> 2) Also interesting is the idea of referencing a table from a block of R >> code elsewhere in the org file. I've worked some on processing >> blocks of R code in org files in a manner similar to Sweave. >> http://github.com/eschulte/org-contrib/tree/master/org-exp-blocks.el >> If we could implement a simple means of referencing tables (either >> whole tables, or cells/cols/rows of tables) from these R-code blocks >> then that seems like it may be fairly powerful. > > I agree with this. So in the case of my code, I think we would like to > be able to do something like > > #+TBLR: data: columns:(1 2) action:tabulate > > This would make the output of the analysis/plot of the table pointed > to by appear at the location in the file of the > #+TBLR line. Perhaps one design aim would be to have the same > mechanism work for referencing tables for processing by #TBLFM, > org-plot, org-table-R, org-exp-blocks, etc. That sounds like a very good idea. A uniform interface for referencing table ranges (either globally from outside of the table or locally from within the table) that could be used for any table formula be it in calc, R, elisp, etc... I find the idea of easily accessing and writing table data from external tools very intriguing > What ideas to people have about implementation (and syntax) for this > sort of table referencing? As for syntax, I believe the syntax currently in use by TBLFM should be sufficient for addressing ranges inside of a table. The only need is the ability to reference a table globally. Maybe it would make sense to allow the naming of a table, say something like a line of the following format either above or below the table. #+TBLNAME: my-table-name Then portions of the table could be references from inside the same file using a syntax like my-table-name:$1@2 or from outside of the file using a syntax like path/to/file.org:my-table-name:$1@2 or something similar. I don't know how difficult this would be to implement. I also don't know how similar the existing calc table interface is to this new R table interface. So basically it's not clear to me how difficult this would be to implement. When I have briefly looked into the mechanics of the current org spreadsheet functionality, I remember being intimidated. Although I don't really use R, I find this discussion very interesting. The spreadsheet functions are one of my favorite features of org. Thanks -- Eric