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

[Derek Feichtinger]

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: address@hidden
Building/Room No. WHGA/U126
CH-5232 Villigen PSI