From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0 Date: Sun, 13 Nov 2016 09:02:36 +0100 Message-ID: <87bmxjst7n.fsf@nicolasgoaziou.fr> References: <74a9bf69-d19e-1528-22ce-f9833d8dd0ed@fgiasson.com> <87mvh6fjiv.fsf@nicolasgoaziou.fr> <9157621c-3c48-8661-9bfb-0f8dadd99357@fgiasson.com> <98645dec-97ad-3d3f-3b1a-291c0dce122d@fgiasson.com> <87wpg9c69m.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c5pkM-0001pD-Ev for emacs-orgmode@gnu.org; Sun, 13 Nov 2016 03:02:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c5pkL-0000h3-6g for emacs-orgmode@gnu.org; Sun, 13 Nov 2016 03:02:38 -0500 Received: from relay4-d.mail.gandi.net ([2001:4b98:c:538::196]:53341) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c5pkK-0000fr-VC for emacs-orgmode@gnu.org; Sun, 13 Nov 2016 03:02:37 -0500 In-Reply-To: (Charles C. Berry's message of "Sat, 12 Nov 2016 19:09:28 -0800") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: "Charles C. Berry" Cc: Org-Mode mailing list Hello, "Charles C. Berry" writes: > OK. I changed the name to `org-export-process-with-babel', which > I hope suggests more profound actions than > `org-export-babel-evaluate'. Thank you. Thinking about it, wouldn't `org-export-use-babel' or even `org-export-with-babel' (as `org-export-with-author'...) be simpler and yet, as clear? > I think the attached patch does this properly, but this is my first > use of `define-obsolete-function-alias', so it might be best to check > what I have done. It looks good. > From 3885129980a02eb0d4694e9e15888dea6ee95c60 Mon Sep 17 00:00:00 2001 > From: Charles Berry > Date: Sat, 12 Nov 2016 18:54:20 -0800 > Subject: [PATCH] make-obsolete-variable `org-export-babel-evaluate' What about: Replace `org-export-babel-evaluate' with `org-export-process-with-babel' > * doc/org.texi: Better explain what the variable > `org-export-process-with-babel' does. > > * lisp/ob-exp.el: Small docstring change. > > * lisp/org-compat.el: Define `org-export-babel-evaluate' as the > obsolete alias for `org-export-process-with-babel'. > > * lisp/ox-icalendar.el, lisp/ox.el, testing/lisp/test-ob-exp.el, > testing/lisp/test-ob-lob.el, testing/lisp/test-ox.el: Change the > obsolete variable name in many places. Could you also specify the functions, or the manual section, being modified? OTOH, I don't think the chande made to "org-compat" requires an entry. > Users were often confused that setting this variable to nil will cause > header arguments to be ignored in addition to preventing code from > being evaluated. It is hoped that the documentation changes and the > name `org-export-process-with-babel' will better convey that everything > babel does can be switched off with this variable. > --- > doc/org.texi | 24 +++++++++++++----------- > lisp/ob-exp.el | 12 ++++++------ > lisp/org-compat.el | 2 ++ > lisp/ox-icalendar.el | 2 +- > lisp/ox.el | 2 +- > testing/lisp/test-ob-exp.el | 36 ++++++++++++++++++------------------ > testing/lisp/test-ob-lob.el | 2 +- > testing/lisp/test-ox.el | 2 +- > 8 files changed, 43 insertions(+), 39 deletions(-) > > diff --git a/doc/org.texi b/doc/org.texi > index ede2352..81364d2 100644 > --- a/doc/org.texi > +++ b/doc/org.texi > @@ -14938,17 +14938,19 @@ Both the code block and its results will be exported. > Neither the code block nor its results will be exported. > @end table > > -It is possible to inhibit the evaluation of code blocks during export. > -Setting the @code{org-export-babel-evaluate} variable to @code{nil} will > -ensure that no code blocks are evaluated as part of the export process. This > -can be useful in situations where potentially untrusted Org mode files are > -exported in an automated fashion, for example when Org mode is used as the > -markup language for a wiki. It is also possible to set this variable to > -@code{inline-only}. In that case, only inline code blocks will be > -evaluated, in order to insert their results. Non-inline code blocks are > -assumed to have their results already inserted in the buffer by manual > -evaluation. This setting is useful to avoid expensive recalculations during > -export, not to provide security. > +It is possible to inhibit the evaluation of code blocks and ignore header > +arguments during export. Setting the @code{org-export-process-with-babel} > +variable to @code{nil} will ensure that no code blocks are evaluated as part > +of the export process. This can be useful in situations where potentially > +untrusted Org mode files are exported in an automated fashion, for example Nitpick: Org files > +when Org mode is used as the markup language for a wiki. No header arguments Nitpick: when Org is used as ... Rationale : in both case, we refer to Org as a markup language, not as an editing mode. > +will be processed. For this reason it is often better to set `:eval > +never-export' to prevent code evaluation but still allow headers to be > +honored. It is also possible to set this variable to @code{inline-only}. In > +that case, only inline code blocks will be evaluated, in order to insert > +their results. Non-inline code blocks are assumed to have their results > +already inserted in the buffer by manual evaluation. This setting is useful > +to avoid expensive recalculations during export, not to provide > security. Could you add @vindex org-export-process-with-babel above the whole paragraph? > Code blocks in commented subtrees (@pxref{Comment lines}) are never evaluated > on export. However, code blocks in subtrees excluded from export > diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el > index 6aebcd5..1d77e6a 100644 > --- a/lisp/ob-exp.el > +++ b/lisp/ob-exp.el > @@ -38,10 +38,10 @@ > > (defvar org-src-preserve-indentation) > > -(defcustom org-export-babel-evaluate t > - "Switch controlling code evaluation during export. > +(defcustom org-export-process-with-babel t > + "Switch controlling code evaluation and header processing during export. > When set to nil no code will be evaluated as part of the export > -process and no header argumentss will be obeyed. When set to > +process and no header arguments will be obeyed. When set to > `inline-only', only inline code blocks will be executed. Users > who wish to avoid evaluating code on export should use the header > argument `:eval never-export'." > @@ -50,7 +50,7 @@ argument `:eval never-export'." > :type '(choice (const :tag "Never" nil) > (const :tag "Only inline code" inline-only) > (const :tag "Always" t))) > -(put 'org-export-babel-evaluate 'safe-local-variable #'null) > +(put 'org-export-process-with-babel 'safe-local-variable #'null) I think it is cleaner to add :safe #'null in the defcustom. Regards, -- Nicolas Goaziou