From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: [PATCH] sha1 hash of latex fragments to avoid regeneration Date: Wed, 23 Dec 2009 08:17:38 -0700 Message-ID: <87aax9u3cd.fsf@gmail.com> References: <6978E5D0-BBB7-4B45-8270-11FDE93F6726@gmail.com> <87ws15zmsm.fsf@missioncriticalit.com> <87ljhfuezt.fsf@missioncriticalit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NNSyD-0006DD-Hc for emacs-orgmode@gnu.org; Wed, 23 Dec 2009 10:17:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NNSy8-0006BJ-Ju for emacs-orgmode@gnu.org; Wed, 23 Dec 2009 10:17:48 -0500 Received: from [199.232.76.173] (port=51685 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NNSy8-0006BE-Dw for emacs-orgmode@gnu.org; Wed, 23 Dec 2009 10:17:44 -0500 Received: from mail-yw0-f202.google.com ([209.85.211.202]:37432) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NNSy8-0008O8-2P for emacs-orgmode@gnu.org; Wed, 23 Dec 2009 10:17:44 -0500 Received: by ywh40 with SMTP id 40so7595947ywh.26 for ; Wed, 23 Dec 2009 07:17:43 -0800 (PST) In-Reply-To: <87ljhfuezt.fsf@missioncriticalit.com> (Francesco Pizzolante's message of "Mon, 07 Dec 2009 13:48:22 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Francesco Pizzolante Cc: mailing-list-org-mode 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[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