From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aaron Ecay Subject: Re: org tables into R? Date: Sun, 04 Jan 2015 19:10:02 -0500 Message-ID: <874ms6w0it.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7vFL-0005Lg-A5 for emacs-orgmode@gnu.org; Sun, 04 Jan 2015 19:10:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y7vFF-0006NF-RR for emacs-orgmode@gnu.org; Sun, 04 Jan 2015 19:10:08 -0500 Received: from mail-qg0-x232.google.com ([2607:f8b0:400d:c04::232]:47850) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7vFF-0006Le-MI for emacs-orgmode@gnu.org; Sun, 04 Jan 2015 19:10:05 -0500 Received: by mail-qg0-f50.google.com with SMTP id z60so14571264qgd.37 for ; Sun, 04 Jan 2015 16:10:05 -0800 (PST) In-Reply-To: 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: Andreas Leha , emacs-orgmode@gnu.org Cc: Nicolas Goaziou --=-=-= Content-Type: text/plain Hi Andreas, Thanks for following up on this problem. 2015ko urtarrilak 4an, Andreas Leha-ek idatzi zuen: > I investigated and found that the culprit is an export filter I have > defined that replaces tabs with spaces: > > --8<---------------cut here---------------start------------->8--- > (defun my-e-beamer-final-filter (contents backend info) > (replace-regexp-in-string "\t" " " contents)) > (add-to-list 'org-export-filter-final-output-functions 'my-e-beamer-final-filter) > --8<---------------cut here---------------end--------------->8--- > > Now, I consider that a bug as well. I am not exporting anything, here. > But I am merely evaluating a code block. Export filters should not > interfere. Plus, it used to work (unfortunately, I do not have the time > to bisect right now). > > So, why are export filters involved? And can that be disabled? Recently(-ish), Nicolas updated the org-table functions to use the export framework. One of the drawbacks of this approach (as you have brought to our attention) is that export filters are invoked. This should probably be disabled. Another drawback is the detection of unexpanded macros (which will be triggered e.g. if a tabular babel result has macro-like {{{text}}} in it). A proof-of-concept patch for this is attached. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-export-allow-sloppy-usage-of-macros-for-internal-API.patch >From 50ce44be96f446272d1e465c01265632f0ed488f Mon Sep 17 00:00:00 2001 From: Aaron Ecay Date: Sun, 4 Jan 2015 18:14:26 -0500 Subject: [PATCH] [export] allow sloppy usage of macros for internal APIs * lisp/ox.el (org-export-as): Support :sloppy-macros plist entry. * lisp/org-table.el (orgtbl-to-generic): Use it. --- lisp/org-table.el | 2 +- lisp/ox.el | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 6b33eda..7a53d7a 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -4834,7 +4834,7 @@ This may be either a string or a function of two arguments: (table-cell . ,(org-table--to-generic-cell params)) ;; Section. Return contents to avoid garbage around table. (section . (lambda (s c i) c)))) - 'body-only (org-combine-plists params '(:with-tables t)))))) + 'body-only (org-combine-plists params '(:with-tables t :sloppy-macros t)))))) (defun org-table--generic-apply (value name &optional with-cons &rest args) (cond ((null value) nil) diff --git a/lisp/ox.el b/lisp/ox.el index f47baef..0fcfc04 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -2885,7 +2885,8 @@ Return code as a string." (cons "email" (or (plist-get info :email) "")) (cons "title" (org-element-interpret-data (plist-get info :title)))) - 'finalize) + (unless (plist-get info :sloppy-macros) + 'finalize)) ;; Parse buffer. (setq tree (org-element-parse-buffer nil visible-only)) ;; Handle left-over uninterpreted elements or objects in -- 2.2.1 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wonder, though, whether the various exceptions like this that will stack up will tip the balance towards its being simpler for org-table to have its own set of functions that operate on the org-element parse tree, but don=E2=80=99t invoke org-export code. For csv this would be some= thing like (pseudocode): (org-element-mapconcat (lambda (table-row) (org-element-mapconcat (lambda (table-cell)=20 (quote-for-csv (org-element-interpret table-cell)) table-row ",")) table "\n") Nicolas, WDYT? If you prefer to continue using the export framework, I can add some commentary to the attached patch and install it. Thanks, --=20 Aaron Ecay --=-=-=--