Hi Francesco,
Francesco Pizzolante 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[bdffac6083
Eric,
> Would it be possible to switch from using org-exp-blocks to using
> org-babel? If so then you could use org-babel's caching which does
> *not* affect the exported file name, but rather saves a sha1 key as
> (mostly) hidden text in the org-mode buffer.
>
> so for example
>
> #+BEGIN_ditaa
Hi Francesco,
You raise good points below, and I am not sure how best to respond to
them. My initial reaction is that you should not be checking
automatically generated files (e.g. the results of ditaa exports) into a
version control repository, however I understand that there are times
when such
Hi,
> I just pulled, reloaded, and re-ran my simple tests and the patch
> appears to have been applied successfully.
This idea of caching images is really great and works well.
Nevertheless, I have a remark about the way it is implemented.
When I write the following code:
--8<---cu
Hi Carsten,
I just pulled, reloaded, and re-ran my simple tests and the patch
appears to have been applied successfully.
Thanks -- Eric
Carsten Dominik writes:
> Hi Eric,
>
> I had a problem while pushing, please verify that the patch got in
> correctly. Thanks!
>
> - Carsten
>
> On Nov 17, 2
Hi Eric,
I had a problem while pushing, please verify that the patch got in
correctly. Thanks!
- Carsten
On Nov 17, 2009, at 4:24 PM, Eric Schulte wrote:
Carsten Dominik writes:
Wow, this is fantastic!
Do you think it is ready to be included (because you say first
pass...)
Yes,
Carsten Dominik writes:
> Wow, this is fantastic!
>
> Do you think it is ready to be included (because you say first pass...)
>
Yes,
I said first pass because I had only done minimal testing. However all
indications are that it works, and there are no further changes I would
like to make, so i
Wow, this is fantastic!
Do you think it is ready to be included (because you say first pass...)
- Carsten
On Nov 17, 2009, at 3:42 AM, Eric Schulte wrote:
"Eric Schulte" writes:
Hi Carsten,
Thanks for the feedback, I have comments inline below
Carsten Dominik writes:
[...]
Now, I am
"
To: Carsten Dominik
Cc: Org Mode
Subject: Re: [Orgmode] [PATCH] sha1 hash of latex fragments to avoid
regeneration
Date: Mon, 16 Nov 2009 17:11:03 -0700
References:
Message-ID:
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (darwin)
MIME-Version: 1.0
Content-Type: multi
"Eric Schulte" writes:
> Hi Carsten,
>
> Thanks for the feedback, I have comments inline below
>
> Carsten Dominik writes:
[...]
>> Now, I am sure that you are already planning to do the same
>> for ditaa images etc?
>
> of course :)
A first pass at a patch implementing caching of ditaa and d
Hi Carsten,
Thanks for the feedback, I have comments inline below
Carsten Dominik 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 ima
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-p
Hi,
The attached patch changes the latex fragment image generation so that
it saves images into files named by the sha1 hash of the latex source
code. By checking for the existence of image files before image
generation the regeneration of identical images is avoided.
In practice I find that thi
13 matches
Mail list logo
