From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: Re: exporting documents w/ babel results w/o evaluating babel blocks Date: Mon, 23 May 2016 13:08:49 -0700 Message-ID: References: <878addc2b6b14ce99e907921f0985d24@HE1PR01MB1898.eurprd01.prod.exchangelabs.com> <87a8jkoec6.fsf@ucl.ac.uk> <87wpmomz6x.fsf@ucl.ac.uk> <871t4wd0to.fsf@alphaville.usersys.redhat.com> <87a8jgocij.fsf@alphaville.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4w9z-0004dh-92 for emacs-orgmode@gnu.org; Mon, 23 May 2016 16:09:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b4w9v-0006Cf-Hl for emacs-orgmode@gnu.org; Mon, 23 May 2016 16:09:06 -0400 Received: from iport-acv3-out.ucsd.edu ([132.239.0.4]:53998) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b4w9v-0006CS-8b for emacs-orgmode@gnu.org; Mon, 23 May 2016 16:09:03 -0400 In-Reply-To: <87a8jgocij.fsf@alphaville.usersys.redhat.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nick Dokos Cc: emacs-orgmode@gnu.org On Mon, 23 May 2016, Nick Dokos wrote: > "Charles C. Berry" writes: > >> TL;DR: Org babel headers give excellent control over what gets run, >> when it gets run, and how. Users should use them. Don't reset >> `org-export-babel-evaluate'. >> >> ... >> [snip] >> >> Frankly, I do not see why users would want to mess with o-e-b-e except >> in unusual cases - like debugging a complicated document, where having >> Babel changing things around could just make things harder. >> > > OK - but then users need guidance that says "don't do that!". Can we add a > big warning to the doc for o-e-b-e? Seems like a good idea. > >> If there is a use case for a capability that is not well supported by >> existing headers it would be good to have an example. >> > > There's the use case that John describes: I've evaluated everything, > checked everything, I'm ready for export, I don't want babel to touch > the results - and I have a million blocks, so I'd rather have a global > setting than go in with individual headers. > > If you've covered this in a previous reply, please ignore me: I've only > paid intermittent attention to the thread, so apologies for missing a > big chunk of what has gone on before in the thread. > Kinda covered it before, but just to elaborate. This line #+PROPERTY: header-args :eval never-export will allow interactive execution via the `org-babel-execute-*' functions. So you can redo one src block, all src blocks in a subtree, or all src blocks in the buffer as you would with `:eval yes'. But on export, it acts like `:eval no'. And of course, the global setting can be overridden by the headers on individual src blocks, so finer control is possible. Chuck