interaction of =org-export-babel-evaluate= and =results output= counter-intuitive

interaction of =org-export-babel-evaluate= and =results output= counter-intuitive

[George Jones]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

   __________________________________________________

    INTERACTION OF `ORG-EXPORT-BABEL-EVALUATE' AND
  `RESULTS OUTPUT' COUNTER-INTUITIVE

     George Jones
  __________________________________________________


<2017-08-15 Tue 08:23>


I want to define code blocks that export only results, and are not
automatically executed on export. To get this behavior, I have to

- `setq org-export-babel-evaluate t)'

and use both

,----
| :eval never-export
| :results output
`----

Which seems a little counter-intuitive.  The problem is that headers
(includiing `:results output') are ignored when
`org-export-babel-evaluate' is set.

Perhaps this headers (at least) should be honored when
`org-export-babel-evaluate' is set?

Is there a way to make `eval never-export' the default?

[-- Attachment #2: Type: text/html, Size: 1455 bytes --]

Re: interaction of =org-export-babel-evaluate= and =results output= counter-intuitive

[Berry, Charles]

> On Aug 15, 2017, at 5:25 AM, George Jones <eludom@gmail.com> wrote:
> 
> 	   __________________________________________________
> 

[snip]

> I want to define code blocks that export only results, and are not
> automatically executed on export. To get this behavior, I have to
> 
> - `setq org-export-babel-evaluate t)'
> 
> and use both
> 
> ,----
> | :eval never-export
> | :results output
> `----
> 


You also need `:exports results'.

HTH,

Chuck

p.s. `org-export-babel-evaluate' is obsolete - use ‘org-export-use-babel’ instead