Hi Nicolas,
Nicolas Goaziou writes:
> Hello,
>
> Martin Carlé writes:
>
>> On 2015-11-04 Wed 14:14, Andreas Leha wrote:
>>
>>> ,---
>>> | > I'd say it is a bug if the results from evaluation differ between
>>> | > manual eva
Hello,
Martin Carlé writes:
> On 2015-11-04 Wed 14:14, Andreas Leha wrote:
>
>> ,---
>> | > I'd say it is a bug if the results from evaluation differ between
>> | > manual evaluation and during export.
>> | >
>> | > And even
On 2015-11-04 Wed 14:14, Andreas Leha wrote:
> ,---
> | > I'd say it is a bug if the results from evaluation differ between
> | > manual evaluation and during export.
> | >
> | > And even if it is not explicitely contradictin
Hi Nick,
Nick Dokos writes:
> Andreas Leha writes:
>
>> ...
>> So, to me it is more surprising that the manual execution works. For
>> instance, I might have two tables with the same name. Then, COMMENTing
>> one of them should ensure that the other one is used.
>>
>
> COMMENT works during exp
Andreas Leha writes:
> ...
> So, to me it is more surprising that the manual execution works. For
> instance, I might have two tables with the same name. Then, COMMENTing
> one of them should ensure that the other one is used.
>
COMMENT works during export *only* I believe. You have to explici
Hi myq,
myq writes:
> Sometime since Org version 8.3beta and now, the way Org Babel resolves
> the value of the `:var` header argument when assigned to a reference has
> changed.
>
> Previously, the following would work when exporting:
>
> * test
>
> #+BEGIN_SRC R :var dat=table-data
> print(su
Sometime since Org version 8.3beta and now, the way Org Babel resolves
the value of the `:var` header argument when assigned to a reference has
changed.
Previously, the following would work when exporting:
--8<---cut here---start->8---
* test
#+BEGIN_SRC R :va
