Hi Carsten,

Thanks for the feedback, I have comments inline below

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi Eric,
>
> this is fantastic, thank you for implementing it.  I have wanted some
> speedup
> for this for a long time.
>
> I think your implementation still suffers from one issue:
>
> The produced image also depends on the variables org-format-latex-
> options,
> org-format-latex-header, org-export-latex-package-alist,
> and on the `forbuffer' flag (because images made for display in
> the buffer and fo HTML export generaly need different resolution).
>
> One way to deal with this would be to make a list containing the values
> of these four variables and using prin1-to-string to convert this list
> into a string, and then to prepend this string to TXT when creating
> the hash.
>

That sounds like the best solution.  I have made this change in the
newly attached patch.

>
> Now, I am sure that you are already planning to do the same
> for ditaa images etc?

of course :)

> That would be a treat, because ditaa can be terribly slow for complex
> figures, and this would speed up the cycle when writing document by
> quite a bit.
>

Dan and I have been working on general caching solution for org-babel.
Once we get that sorted out it should provide for the caching of all
org-babel results which would include ditaa, dot, gnuplot, etc...

I am currently more interested in making these changes in org-babel than
in org-exp-blocks, but in this case it may be worth implementing caching
in both cases.

>
> There is one further issue:  Cleaning up images that are no
> longer used.
>
> With the LaTeX fragments it is not a big problem, because there
> live in a special directory.  This would be a bigger concern for
> ditaa images etc which tend to live in the same directory as the
> source.  Maybe that could be solved by
>
> 1. Making sure that each image still have a name like "blue", so
>    that the name now would be "blus_loooooonghashvalue.png" or so.
> 2. Maybe creating a command that will look for orphaned images
>    and remove them, by looking for the hash in the name and
>    checking access times.  I am not sure if this is needed,
>    and not sure what would be the best way to implement it.
>

Yes, this will not be an issue in the org-babel implementation as the
hash key is stored separate from the file name, but I can see how this
would need to be considered for any org-exp-blocks hash-based image
caching.  The first option you propose above sounds very doable, as long
as we are comfortable removing any files that match regular expressions
like

  blue_[[:alnum:]]+\.png

which seems safe enough...

>
> After looking at these things, I would be *very* happy to accept
> this patch.
>

I'll give this some more thought, but perhaps the latex image fragment
patch is now viable.

Best -- Eric