Re: org tables into R?

[Aaron Ecay <aaronecay@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-export-allow-sloppy-usage-of-macros-for-internal-API.patch --]
[-- Type: text/x-diff, Size: 1576 bytes --]

From 50ce44be96f446272d1e465c01265632f0ed488f Mon Sep 17 00:00:00 2001
From: Aaron Ecay <aaronecay@gmail.com>
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


[-- Attachment #3: Type: text/plain, Size: 681 bytes --]


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’t invoke org-export code.  For csv this would be something
like (pseudocode):

(org-element-mapconcat
 (lambda (table-row)
   (org-element-mapconcat
    (lambda (table-cell) 
      (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,

-- 
Aaron Ecay