From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Re: Using babel to generate a commit log Date: Wed, 30 Mar 2011 12:51:05 -0400 Message-ID: <5188.1301503865@alphaville.usa.hp.com> References: <20110329232804.45777e7a@bhishma.homelinux.net> <8080.1301490442@alphaville.dokosmarshall.org> Reply-To: nicholas.dokos@hp.com Return-path: Received: from [140.186.70.92] (port=34563 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4ybu-0000gE-OO for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 12:51:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4ybt-0001Kz-H0 for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 12:51:10 -0400 Received: from g4t0016.houston.hp.com ([15.201.24.19]:25417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4ybt-0001Kq-DY for emacs-orgmode@gnu.org; Wed, 30 Mar 2011 12:51:09 -0400 In-Reply-To: Message from Luke Crook of "Wed, 30 Mar 2011 15:34:32 -0000." 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: Luke Crook Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org Luke Crook wrote: > Nick Dokos hp.com> writes: > > > > > Luke Crook balooga.com> wrote: > > > > > Suvayu Ali gmail.com> writes: > > > > > > > Have you tried ':exports results' as a header argument? > > > > > > > > > > I just tried ':exports results'. But now I get the following error when > > > exporting the file, "Cannot open load file: vc-nil" > > > > > > > That sounds like vc does not know what backend to use: maybe you are not > > in a git-controlled directory? > > > > '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. Nick