From mboxrd@z Thu Jan  1 00:00:00 1970
From: Aaron Ecay <aaronecay@gmail.com>
Subject: Re: org tables into R?
Date: Tue, 06 Jan 2015 18:17:55 -0500
Message-ID: <87fvbnv6qk.fsf@gmail.com>
References: <loom.20150102T205112-477@post.gmane.org>
	<olufvbtgcvc.fsf@med.uni-goettingen.de>
	<B874ADA0-1879-4021-B873-035AC85C4F47@agrarianresearch.org>
	<olubnmehnjr.fsf@med.uni-goettingen.de>
	<874ms6w0it.fsf@gmail.com> <87zj9xa1ni.fsf@nicolasgoaziou.fr>
	<87r3v8v8hx.fsf@gmail.com> <87d26ra4nf.fsf@nicolasgoaziou.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34018)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1Y8dNw-0005XT-L8
	for emacs-orgmode@gnu.org; Tue, 06 Jan 2015 18:18:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1Y8dNt-0004fJ-Fl
	for emacs-orgmode@gnu.org; Tue, 06 Jan 2015 18:18:00 -0500
Received: from mail-qc0-x232.google.com ([2607:f8b0:400d:c01::232]:36491)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aaronecay@gmail.com>) id 1Y8dNt-0004fF-BS
	for emacs-orgmode@gnu.org; Tue, 06 Jan 2015 18:17:57 -0500
Received: by mail-qc0-f178.google.com with SMTP id p6so204132qcv.9
	for <emacs-orgmode@gnu.org>; Tue, 06 Jan 2015 15:17:57 -0800 (PST)
In-Reply-To: <87d26ra4nf.fsf@nicolasgoaziou.fr>
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=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: Nicolas Goaziou <mail@nicolasgoaziou.fr>, emacs-orgmode@gnu.org

Hi Nicolas,

2015ko urtarrilak 6an, Nicolas Goaziou-ek idatzi zuen:
>=20
> Aaron Ecay <aaronecay@gmail.com> writes:
>=20
>> You are correct about the silent dropping of macro-like text.  However,
>> with current master that case gives an undefined macro error, which is
>> even worse.
>=20
> I disagree. If we allow to insert macro-like text in the table, it will
> become active in the generated table and will, sooner or later, generate
> an undefined macro error anyway.
>=20
>> Try this (in emacs -Q with org and ESS in the load-path) to
>> see it:
>>=20
>> #+name: foo
>> #+begin_src R
>> c("foo","{{{bar}}}")
>> #+end_src
>=20
> Yes, an error is thrown, but
>=20
>   #+RESULTS: foo
>   |    foo    |
>   | {{{bar}}} |
>=20
> is as cheesy. See above.
>=20
> Macros are a very special kind of datum in Org. Luckily, their syntax is
> awkward so you're unlikely to create one unwillingly. How common is your
> example?

Nothing unwilling about it =E2=80=93 I had been deliberately trying to gene=
rate a
table with macros in it as the result of a babel block.  These macros are
defined in the document, in order to encapsulate some fiddly typesetting
which recurs very commonly.

Shouldn=E2=80=99t this workflow be supported?

In any case, the point is broader: the orgtbl-* functions cannot cope
with macros in their input at all (not just in the context of babel).  I
think the programmatic interface to org tables ought to be composable
with macros.

Thanks,

--=20
Aaron Ecay