Re: [Orgmode] [PATCH] sha1 hash of latex fragments to avoid regeneration

[Eric Schulte]

Hi Francesco,

Francesco Pizzolante <address@hidden> writes:

>>
>> and pressing C-cC-c on the block (or exporting) would result in the
>> insertion of a link to the resulting image into the org-mode buffer
>> behind a results line as follows -- only in org most of the hash is
>> hidden.
>>
>> #+results[bdffac60833c9f925a52bd6617dace39832b7dda]:
>> [[file:procedure.png]]
>
> I don't see any problem in using org-babel. The only issues I see with this
> solution are the following:
>
> - when you export, no #+results line is added to the org-mode buffer;
>
> - you, thus, have to do the C-cC-c at least once in your block to generate
>   the #+results line;
>

Yes, this is true, and this is how I generally do development with
Org-babel.  In most cases I'd rather generate the image with C-cC-c and
preview the image with C-cC-o before exporting the document.  My most
common setup is to construct source-code blocks like the following

--8<---------------cut here---------------start------------->8---
#+begin_src ditaa :file data/example.png :exports none
    +------------------+
    |  ditaa example   |
    |                  |
    |                  |
    +------------------+
#+end_src

#+results:
[[file:data/example.png]]
--8<---------------cut here---------------end--------------->8---

in which case the caching isn't even used as *no* action is taken on the
source-code block during export

>
> - when you export (to LaTeX or PDF), the image is always re-computed (no
>   caching mechanism is used), while doing C-cC-c, the caching is used.
>
> Can you confirm these points?
>

Yes, these points are both very valid.  Exporting should not change the
buffer being exported, however, that leaves caching no way to save it's
results aside from the somewhat hackey out-of-file solutions used
elsewhere.  When we were initially working on caching Dan had a solution
which saved cache information in memory which allowed caching on export
without any file/buffer changes but which saved information during the
current Emacs session.  I believe he also worked out a caching system
which stored this same information in a single system-wide file.  If
there is enough interest perhaps it would be worth resurrecting these
ideas.

Thanks -- Eric