emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Eric Schulte" <schulte.eric@gmail.com>
To: Dan Davison <dandavison7@gmail.com>
Cc: Loris Bennett <loris.bennett@fu-berlin.de>, emacs-orgmode@gnu.org
Subject: Re: Re: Suppressing src block evaluationon publish?
Date: Thu, 03 Feb 2011 07:34:30 -0700	[thread overview]
Message-ID: <878vxxp3ed.fsf@gmail.com> (raw)
In-Reply-To: m17hdhwghb.fsf@94.197.213.136.threembb.co.uk

Dan Davison <dandavison7@gmail.com> writes:

> Loris Bennett <loris.bennett@fu-berlin.de> writes:
>
>> Erik Iverson <eriki@ccbr.umn.edu> writes:
>>
>>> Loris Bennett wrote:
>>>> Hi,
>>>>
>>>> I have an org file containing several src blocks which generate images
>>>> using ditaa. When I publish to PDF via LaTeX, the images are all
>>>> generated every time, which makes publishing rather slow.
>>>>
>>>> Is there some way to toggle the evaluation of the src blocks on and off
>>>> when the file is published?
>>>>
>>>
>>> You could try the :cache header argument, http://orgmode.org/org.html#cache
>>>
>>
>> Ah, thanks. There is a slight gotcha here, though.
>>
>> I added :cache yes to the source headers and exported again, but nothing
>> changed; all the images were generated again. Also, no SHA1 hash was
>> added to the +results header.
>>
>> After some fruitless fiddling I was about to write to the list again and
>> moan, when I did a slightly random C-c C-c in the begin_src line and,
>> hey presto, the hash was added to the results header. I then did this
>> for all the images and found that the image were no longer regenerated
>> on export, as advertised.
>
> Hi Loris,
>
> Yes. It does seem that it would be nice if in this situation, the first
> export added the SHA1s, and subsequent exports recognized that
> evaluation wasn't required. I think the reason this does not happen is
> that behind-the-scenes Org makes a copy of the buffer for export
> preprocessing (including src block evaluation). But Eric S is the expert
> -- he may have more to say here.
>

Yes, this is exactly the case.  Org-mode is very careful that the
process of exporting does not make any permanent changes to the original
org-mode file.  I agree this should be mentioned in the :cache
documentation.

Best -- Eric

  reply	other threads:[~2011-02-03 15:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-01 15:56 Suppressing src block evaluationon publish? Loris Bennett
2011-02-01 16:06 ` Erik Iverson
2011-02-03  8:19   ` Loris Bennett
2011-02-03 10:38     ` Dan Davison
2011-02-03 14:34       ` Eric Schulte [this message]
2011-02-17 17:09         ` Andreas Leha
2011-02-01 16:35 ` Andrea Crotti
2011-02-01 16:37 ` Andrea Crotti

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878vxxp3ed.fsf@gmail.com \
    --to=schulte.eric@gmail.com \
    --cc=dandavison7@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=loris.bennett@fu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).