Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed

[Derek Feichtinger <derek.feichtinger@psi.ch>]

Hi Colin

On 22.02.2017 16:27, Colin Baxter wrote:
> 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.
>
Based on the documentation one can set the header arguments system wide 
using these variables:

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: derek.feichtinger@psi.ch
Building/Room No. WHGA/U126
CH-5232 Villigen PSI