From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luke Crook Subject: Re: Using babel to generate a commit log Date: Wed, 30 Mar 2011 17:47:34 +0000 (UTC) Message-ID: References: <20110329232804.45777e7a@bhishma.homelinux.net> <8080.1301490442@alphaville.dokosmarshall.org> <5188.1301503865@alphaville.usa.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=60703 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4zUi-0007oL-Gd for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 13:47:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4zUh-0006Jl-6T for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 13:47:48 -0400 Received: from lo.gmane.org ([80.91.229.12]:32869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4zUh-0006JW-13 for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 13:47:47 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Q4zUf-0000t6-0U for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 19:47:45 +0200 Received: from 147.21.8.1 ([147.21.8.1]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 19:47:44 +0200 Received: from luke by 147.21.8.1 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 30 Mar 2011 19:47:44 +0200 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: emacs-orgmode@gnu.org Nick Dokos hp.com> writes: > > Luke Crook balooga.com> wrote: > > > 'C-c C-c' at the top of the source block does generate the correct output > > though. It is just 'C-c C-e ' that returns this error. > > > > Right: (current-buffer) is not what you think it is when exporting - it is > the temp buffer that the export mechanism sets up. > > There is a way to get the original buffer during capture, but I don't > know of a similar mechanism during export. I hardwired the file name > instead, but I got no further than the vc-fileset call: there seem to be > all sorts of contextual assumptions that vc makes that are violated in > the export context. Yes, this makes sense thanks. I'll create another thread asking how to retrieve the original buffer during the export process. -Luke