emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Derek Feichtinger <derek.feichtinger@psi.ch>
To: "Charles C. Berry" <ccberry@ucsd.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed
Date: Tue, 21 Feb 2017 07:05:54 +0100	[thread overview]
Message-ID: <4a762d44-3d98-0caa-0e2d-3ff515f8f3c9@psi.ch> (raw)
In-Reply-To: <alpine.OSX.2.20.1702201539500.2883@charles-berrys-macbook.local>

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:
>
In my current version from MELPA the info text is not yet reflecting 
this change. Thanks for pointing me to it.


> ,----[ C-h v org-export-babel-evaluate RET ]
> | org-export-babel-evaluate is a variable defined in ‘org-compat.el’.
> | Its value is t
> |
> |   This variable is an alias for ‘org-export-use-babel’.
> |   This variable is obsolete since Org 9.1;
> |   use ‘org-export-use-babel’ instead.
>
> and here
>
>      (info "(org) Exporting code blocks")
>
>> I think that this should be considered a bug.
>
> Allowing header args to be processed (as before) also allows for 
> arbitrary code to be executed.  The point of setting 
> ‘org-export-use-babel’ or `org-export-babel-evaluate' to nil was to 
> prevent this.  For that reason the former behavior was a bug.
>
OK. I can see that one wants to prevent most header args of babel blocks 
from being reeavaluated, but the :exports argument does not affect 
evaluation, but simply the representation of the result exported to the 
target document. So, I think that this argument still should be 
observed. Otherwise the resulting document would be completely changed 
once I introduce ‘org-export-use-babel’. I might want to introduce it to 
conserve the current code block results, while still being very much 
interested in exporting it to a different format, or re-exporting it at 
a later point (after having added new chapters that are manually evaluated).

So, I still feel that this is a very much needed functionality that has 
been lost on the way. I have made many documents over the last few years 
that relied on this functionality, e.g. files collecting logs or 
producing analysis results that were dependent on a particular state of 
a system at that moment of time. I hope that the observing of the 
:exports argument can be reintroduced.

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

  reply	other threads:[~2017-02-21  6:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-20 22:02 org-export-babel-evaluate=nil ignores ":exports results" setting - this has changed Derek Feichtinger
2017-02-20 23:54 ` Charles C. Berry
2017-02-21  6:05   ` Derek Feichtinger [this message]
2017-02-21 16:37     ` Charles C. Berry
2017-02-22 15:27       ` Colin Baxter
2017-02-22 15:45         ` Derek Feichtinger
2017-02-22 18:56           ` Colin Baxter
2017-02-21 10:51   ` Aaron Ecay
2017-02-21 16:40     ` Charles C. Berry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a762d44-3d98-0caa-0e2d-3ff515f8f3c9@psi.ch \
    --to=derek.feichtinger@psi.ch \
    --cc=ccberry@ucsd.edu \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).