Hi Nicolas,
2015ko urtarrilak 6an, Nicolas Goaziou-ek idatzi zuen:
>
> Aaron Ecay <aarone...@gmail.com> writes:
>
>> 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.
>
> 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.
>
>> Try this (in emacs -Q with org and ESS in the load-path) to
>> see it:
>>
>> #+name: foo
>> #+begin_src R
>> c("foo","{{{bar}}}")
>> #+end_src
>
> Yes, an error is thrown, but
>
> #+RESULTS: foo
> | foo |
> | {{{bar}}} |
>
> is as cheesy. See above.
>
> 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 – I had been deliberately trying to generate 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’t 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,
--
Aaron Ecay
