|
From: | Derek Feichtinger |
Subject: | Re: [O] org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed |
Date: | Wed, 22 Feb 2017 16:45:26 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
Hi Colin On 22.02.2017 16:27, Colin Baxter wrote:
Based on the documentation one can set the header arguments system wide using these variables:Hi. On Tue, Feb 21 2017, Charles C. Berry wrote:On Mon, 20 Feb 2017, Derek Feichtinger wrote:Hi Chuck On 21.02.2017 00:54, Charles C. Berry wrote:On Mon, 20 Feb 2017, Derek Feichtinger wrote:When org-export-babel-evaluate is set to nil, I see a different behavior now as compared to earlier versions of org.Indeed. It is now *obsolete* and its behavior has intentionally been changed as noted here:So, I still feel that this is a very much needed functionality that has been lost on the way.Nothing is lost here. Reread the part of my post that you deleted in your reply: : | ... Users : | who wish to avoid evaluating code on export should use the header : | argument ‘:eval never-export’. : | which is how to do what you want. And maybe review how to set header args buffer wide or system-wide.I agree very much with the sentiments expressed by Derek Feichtinger. The old org-export-babel-evaluate allowed a setting to be made for one or several files. Perhaps I've not understood correctly, but the new arrangement would seem to suggest that the user has to insert what they want at each src_code block.
org-babel-default-header-args (for all) org-babel-default-header-args:<lang> (language specific) File wide using PROPERTY: #+PROPERTY: header-args :eval never-export Org heading wide using a local property setting: * sample header :PROPERTIES: :header-args: :eval never-export :END:The last two ways I tested. So, in the end, with some changes to most of my files I can get the same behavior again, which is good.
It's a matter of taste or use case whether to define the default behavior to eval on export. I would have made the case the eval on export is the more rare use case. I almost never have this, except for certain kinds of reports, e.g. if you want to gather the state of a server with a number of prepared queries in the org file. For me, most org files are like a number of measurements taken at a certain point in time, and I want to conserve the output of the evaluation exactly like it was. E.g. when working at speeding up code, I very much like to do the whole thing inside of an org file where I document the speed measurements, my changes to code and what the effect was. So, more like some kind of interactive lab journal.
But as I said, it is a matter of taste, and I am happy that I can get the original functionality without too much effort.
Best regards, Derek -- Paul Scherrer Institut Dr. Derek Feichtinger Phone: +41 56 310 47 33 Section Head Science-IT Email: address@hidden Building/Room No. WHGA/U126 CH-5232 Villigen PSI
[Prev in Thread] | Current Thread | [Next in Thread] |