Sébastien Vauban writes:
>>> I guess one possibility would be to have a header argument
>>> (update-results-when-exporting) which, if set, would update all results
>>> in the org buffer and export then.
>>
>> This can also be accomplished using an export hook. e.g.
>>
>>
>
> Thanks Eric for thi
Hi Rainer and Eric,
Rainer M Krug wrote:
>> Here the distinction (or view) of what the org file is comes in: as you see
>> it, the org-file is a *usable result* in itself and already the *final
>> product*. Then, it *has* to reflect (and be identical to) the exported one.
>>
>> If, on the other ha
Rainer M Krug writes:
>
> I guess one possibility would be to have a header argument
> (update-results-when-exporting) which, if set, would update all results
> in the org buffer and export then.
>
This can also be accomplished using an export hook. e.g.
(add-hook 'org-export-first-hook 'org-b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/16/2010 10:48 AM, Sébastien Vauban wrote:
> Hi Andreas,
>
> Andreas Leha wrote:
>> is there an option (source block header argument) that allows to disable the
>> evaluation of the block, but still allows C-c C-c to perform the evaluation?
>> Th
Hi all,
hi Sébastien, thanks for your answer, which adds much more in-depth
information to my problem. In fact, what you describe is probably the
bigger problem.
But for me (maybe I am the only one ...) it would be handy to have
source blocks, that are evaluated on C-c C-c *only*. That also mea
Hi Andreas,
Andreas Leha wrote:
> is there an option (source block header argument) that allows to disable the
> evaluation of the block, but still allows C-c C-c to perform the evaluation?
> The header argument ':eval never' disables the evaluation completely. I'd
> like the C-c C-c to take prece
