From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: Re: [babel] apply #+TABLEFM lines during export? Date: Mon, 12 Jul 2010 22:06:44 -0700 Message-ID: <87zkxwgecb.fsf@gmail.com> References: <87hbk5mh9j.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=51011 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYXhh-00088i-Us for emacs-orgmode@gnu.org; Tue, 13 Jul 2010 01:06:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYXhg-0006qI-Pd for emacs-orgmode@gnu.org; Tue, 13 Jul 2010 01:06:49 -0400 Received: from mail-px0-f169.google.com ([209.85.212.169]:41371) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYXhg-0006q5-H1 for emacs-orgmode@gnu.org; Tue, 13 Jul 2010 01:06:48 -0400 Received: by pxi7 with SMTP id 7so2983303pxi.0 for ; Mon, 12 Jul 2010 22:06:47 -0700 (PDT) In-Reply-To: (Austin Frank's message of "Mon, 12 Jul 2010 22:59:42 -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: Austin Frank Cc: emacs-orgmode@gnu.org Austin Frank writes: > On Sun, Jul 11 2010, Eric Schulte wrote: > >> Under the current setup, I don't know of a way to ensure that the >> formula will be re-run. This may be a good place for future >> (post-feature-freeze) functionality. There has also been discussion >> of adding a header argument for "post-processing" code blocks which >> could accept the output of the evaluated code block as input -- this >> might be related. > > Yes, eager to see where this goes. > >> As a work-around, I would suggest the following emacs-lisp code block. >> Export of this code block will trigger the evaluation of the R code >> block, and it will then trim the output of said block resulting in the >> desired table precision. >> >> #+begin_src emacs-lisp :var tab=anova-example :colnames yes :cache yes >> (mapcar >> (lambda (row) >> (mapcar >> (lambda (cell) (if (numberp cell) (format "%.4f" cell) cell)) >> row)) >> tab) >> #+end_src > > > I tried to customize your approach to apply to the whole buffer. This > code seems to do a nice job of changing the appearance of the tables > within the buffer, but the extra precision is still maintained on > export. > if you want to use my approach above more widely you could name the code block say #+source:less-precision, then add :exports none to each of your existing code blocks that output over-precise data, and for each such block add a call of the following form #+call: less-precision(tab=overly-precise-R-block) :exports results which should work, but would litter your file with these call lines. I guess this is an instance where a post-processing function specified at the file/subtree level could potentially be useful. Cheers -- Eric > > #+source: format-table-floats > #+BEGIN_SRC emacs-lisp :results silent :exports none > (add-hook 'org-export-preprocess-final-hook > (lambda () > (while (re-search-forward > "|?[ ]+\\(-?[0-9]+\\.[0-9]+\\)\\(e-\\)?[ ]+|" > nil t) > (progn > (replace-match (concat > (format "%.4f" > (string-to-number (match-string 1))) > " |")) > (org-table-align))))) > #+END_SRC > > Can anyone suggest another approach that would change the precision of > floats in all tables in the buffer before export? Perhaps there's a > different hook I should be using for LaTeX export? > > Thanks! > /au