From: Aaron Ecay <aaronecay@gmail.com>
To: Andreas Leha <andreas.leha@med.uni-goettingen.de>, emacs-orgmode@gnu.org
Cc: Nicolas Goaziou <n.goaziou@gmail.com>
Subject: Re: org tables into R?
Date: Sun, 04 Jan 2015 19:10:02 -0500 [thread overview]
Message-ID: <874ms6w0it.fsf@gmail.com> (raw)
In-Reply-To: <olubnmehnjr.fsf@med.uni-goettingen.de>
[-- 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
next prev parent reply other threads:[~2015-01-05 0:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-02 19:57 org tables into R? Michael Gauland
2015-01-02 20:13 ` Andreas Leha
2015-01-02 22:45 ` Vikas Rawal
2015-01-04 10:01 ` Andreas Leha
2015-01-05 0:10 ` Aaron Ecay [this message]
2015-01-05 11:48 ` Nicolas Goaziou
2015-01-06 4:27 ` Aaron Ecay
2015-01-06 23:08 ` Nicolas Goaziou
2015-01-06 23:17 ` Aaron Ecay
2015-01-06 23:38 ` Nicolas Goaziou
2015-01-06 10:14 ` Andreas Leha
2015-01-06 11:02 ` Rainer M Krug
2015-01-06 12:07 ` Andreas Leha
2015-01-06 13:37 ` Rainer M Krug
2015-01-06 17:49 ` Aaron Ecay
2015-01-07 9:01 ` Rainer M Krug
2015-01-04 3:19 ` Michael Gauland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874ms6w0it.fsf@gmail.com \
--to=aaronecay@gmail.com \
--cc=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).