Nicolas Goaziou writes:
>> The bug was that Babel blocks were evaluated during export when
>> org-export-babel-evaluate was explicitly set to nil (the default value
>> is t).
>
> AFAICT, they aren't.
So let's go back to the OP (Gregor Kappler, IIRC) and ask for a
reproducible recipe.
Regards,
Ac
Achim Gratz writes:
> Nicolas Goaziou writes:
>> I'm just starting over because that wasn't a correct solution. I'm not
>> even sure about what bug this patch fixed.
>
> The bug was that Babel blocks were evaluated during export when
> org-export-babel-evaluate was explicitly set to nil (the defa
On Fri, Feb 22, 2013 at 3:49 PM, Achim Gratz wrote:
> Nicolas Goaziou writes:
>> I'm just starting over because that wasn't a correct solution. I'm not
>> even sure about what bug this patch fixed.
>
> The bug was that Babel blocks were evaluated during export when
> org-export-babel-evaluate was
Nicolas Goaziou writes:
> I'm just starting over because that wasn't a correct solution. I'm not
> even sure about what bug this patch fixed.
The bug was that Babel blocks were evaluated during export when
org-export-babel-evaluate was explicitly set to nil (the default value
is t).
> Anyway, it
Hello,
Achim Gratz writes:
> Nicolas Goaziou writes:
>> I confirm the problem. It is coming from
>> 12d592b73223f3b0628e10f0f627447b1a312203. I reverted it.
>
> Doesn't this throw the baby out with the bathtub? If anything that's an
> indication that the evaluation and the exporting of a block
On Mon, Feb 18, 2013 at 3:17 PM, Nicolas Goaziou wrote:
> Hello,
>
> Ista Zahn writes:
>
>> Thanks for checking Jay. I just tried with make update2 (usually I use
>> make update), with the same result as I got before (i.e., the code
>> block is exported). Just to make sure -- you ran the test wit
Nicolas Goaziou writes:
> I confirm the problem. It is coming from
> 12d592b73223f3b0628e10f0f627447b1a312203. I reverted it.
Doesn't this throw the baby out with the bathtub? If anything that's an
indication that the evaluation and the exporting of a block should be
independently controllable.
Nicolas Goaziou writes:
> I confirm the problem. It is coming from
> 12d592b73223f3b0628e10f0f627447b1a312203. I reverted it.
Doesn't this throw the baby out with the bathtub? If anything that's an
indication that the evaluation and the exporting of a block should be
independently controllable.
Hello,
Ista Zahn writes:
> Thanks for checking Jay. I just tried with make update2 (usually I use
> make update), with the same result as I got before (i.e., the code
> block is exported). Just to make sure -- you ran the test with emacs
> -q right?
>
> Anybody else try this?
> Thanks!
> Ista
I
On Mon, Feb 18, 2013 at 1:59 PM, Jay Kerns wrote:
> Dear Ista,
>
>
> On Mon, Feb 18, 2013 at 1:22 PM, Ista Zahn wrote:
>> Hi all,
>>
>> Just checking to see if anyone was able to reproduce this or if I am
>> the only one with this problem.
>>
>> Thanks,
>> Ista
>
> I just make update2'ed, followe
Dear Ista,
On Mon, Feb 18, 2013 at 1:22 PM, Ista Zahn wrote:
> Hi all,
>
> Just checking to see if anyone was able to reproduce this or if I am
> the only one with this problem.
>
> Thanks,
> Ista
I just make update2'ed, followed your recipe, but my tmp.tex did not
incorrectly have the exported
Hi all,
Just checking to see if anyone was able to reproduce this or if I am
the only one with this problem.
Thanks,
Ista
On Sun, Feb 17, 2013 at 9:24 AM, Ista Zahn wrote:
> Hi,
>
> I upgraded to the latest git version yesterday, and am loving the new
> exporter. Congrats to all involved!
>
> H
Hi,
I upgraded to the latest git version yesterday, and am loving the new
exporter. Congrats to all involved!
However, when I set org-export-babel-evaluate to nil the new latex
exporter (I have not tried the others) ignores :exports none source
block header arguments. To reproduce:
1. start emac
13 matches
Mail list logo
