* HTML export with ":export" parameter with Orgmode 9.0
@ 2016-11-08 13:30 Frederick Giasson
2016-11-11 9:33 ` Nicolas Goaziou
0 siblings, 1 reply; 13+ messages in thread
From: Frederick Giasson @ 2016-11-08 13:30 UTC (permalink / raw)
To: emacs-orgmode
Hi,
I am not clear about the change in the Export blocks that occurred in
Org-mode 9.0
Does this change impact the ":export [...]" code block header parameter?
What I am often using is this:
http://orgmode.org/manual/Exporting-code-blocks.html
Which currently doesn't work but it is unclear from the release notes if
it should or not and the code provided to fix the Export blocks doesn't
appear to look for this syntax, so I guess it should still be working.
Anybody else experience this issue?
Thanks,
Fred
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-08 13:30 HTML export with ":export" parameter with Orgmode 9.0 Frederick Giasson @ 2016-11-11 9:33 ` Nicolas Goaziou 2016-11-11 14:11 ` Frederick Giasson 2016-11-11 17:10 ` Frederick Giasson 0 siblings, 2 replies; 13+ messages in thread From: Nicolas Goaziou @ 2016-11-11 9:33 UTC (permalink / raw) To: Frederick Giasson; +Cc: emacs-orgmode Hello, Frederick Giasson <fred@fgiasson.com> writes: > Does this change impact the ":export [...]" code block header > parameter? What I am often using is this: > > > http://orgmode.org/manual/Exporting-code-blocks.html > > > Which currently doesn't work but it is unclear from the release notes > if it should or not and the code provided to fix the Export blocks > doesn't appear to look for this syntax, so I guess it should still be > working. > > > Anybody else experience this issue? It seems other users experienced it, yet it is unexpected and I cannot reproduce it even with a minimal init file. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-11 9:33 ` Nicolas Goaziou @ 2016-11-11 14:11 ` Frederick Giasson 2016-11-11 17:21 ` Charles C. Berry 2016-11-11 17:10 ` Frederick Giasson 1 sibling, 1 reply; 13+ messages in thread From: Frederick Giasson @ 2016-11-11 14:11 UTC (permalink / raw) To: emacs-orgmode Hi Nicolas, > It seems other users experienced it, yet it is unexpected and I cannot > reproduce it even with a minimal init file. Ok good. I will try to do some debugging on my side. I am wondering if it may not be a Windows issue, or some older 8.x configurations that may be at cause here. Will keep you updated. Thanks, Fred ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-11 14:11 ` Frederick Giasson @ 2016-11-11 17:21 ` Charles C. Berry 2016-11-11 18:15 ` Frederick Giasson 0 siblings, 1 reply; 13+ messages in thread From: Charles C. Berry @ 2016-11-11 17:21 UTC (permalink / raw) To: Frederick Giasson; +Cc: emacs-orgmode On Fri, 11 Nov 2016, Frederick Giasson wrote: > Hi Nicolas, > >> It seems other users experienced it, yet it is unexpected and I cannot >> reproduce it even with a minimal init file. If you ever set the value of `org-export-babel-evaluate' to nil this might produce the behavior you describe. In that case, see the docstring for advice. HTH, Chuck ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-11 17:21 ` Charles C. Berry @ 2016-11-11 18:15 ` Frederick Giasson 2016-11-12 3:21 ` Charles C. Berry 0 siblings, 1 reply; 13+ messages in thread From: Frederick Giasson @ 2016-11-11 18:15 UTC (permalink / raw) To: emacs-orgmode Hi Chuck, > even with a minimal init file. > > If you ever set the value of `org-export-babel-evaluate' to nil this > might produce the behavior you describe. Maybe, but as stated in the manual: "Setting the org-export-babel-evaluate variable to nil will ensure that no code blocks are evaluated as part of the export process." From here: http://orgmode.org/manual/Exporting-code-blocks.html The thing is that I indeed want to make sure that the code blocks are evaluated, but to me evaluation of code block is different than what to export from the Org file. It is often the case that I don't want export to evaluate anything, but just to export what is in the Org file's markup (while following what the header parameters say). Thanks, Fred ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-11 18:15 ` Frederick Giasson @ 2016-11-12 3:21 ` Charles C. Berry 2016-11-12 11:00 ` Nicolas Goaziou 2016-11-14 13:32 ` Frederick Giasson 0 siblings, 2 replies; 13+ messages in thread From: Charles C. Berry @ 2016-11-12 3:21 UTC (permalink / raw) To: Frederick Giasson; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1273 bytes --] On Fri, 11 Nov 2016, Frederick Giasson wrote: > Hi Chuck, > >> even with a minimal init file. >> >> If you ever set the value of `org-export-babel-evaluate' to nil this might >> produce the behavior you describe. > > Maybe, but as stated in the manual: "Setting the org-export-babel-evaluate > variable to nil will ensure that no code blocks are evaluated as part of the > export process." Argh! That paragraph needs to be revised. > > From here: http://orgmode.org/manual/Exporting-code-blocks.html > > The thing is that I indeed want to make sure that the code blocks are > evaluated, but to me evaluation of code block is different than what to > export from the Org file. It is often the case that I don't want export to > evaluate anything, but just to export what is in the Org file's markup (while > following what the header parameters say). > Setting `org-export-babel-evaluate' to nil will ensure that NONE of your header arguments are followed. Like the docstring says "Users who wish to avoid evaluating code on export should use the header argument ‘:eval never-export’." It is tempting to `make-obsolete-variable' this variable and change its name to something that more completely describes what does not happen when set to nil. Chuck ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-12 3:21 ` Charles C. Berry @ 2016-11-12 11:00 ` Nicolas Goaziou 2016-11-13 3:09 ` [PATCH] " Charles C. Berry 2016-11-14 13:32 ` Frederick Giasson 1 sibling, 1 reply; 13+ messages in thread From: Nicolas Goaziou @ 2016-11-12 11:00 UTC (permalink / raw) To: Charles C. Berry; +Cc: emacs-orgmode, Frederick Giasson Hello, "Charles C. Berry" <ccberry@ucsd.edu> writes: > On Fri, 11 Nov 2016, Frederick Giasson wrote: > >> Hi Chuck, >> >>> even with a minimal init file. >>> >>> If you ever set the value of `org-export-babel-evaluate' to nil >>> this might produce the behavior you describe. >> >> Maybe, but as stated in the manual: "Setting the >> org-export-babel-evaluate variable to nil will ensure that no code >> blocks are evaluated as part of the export process." > > Argh! That paragraph needs to be revised. Do you want to provide a patch for that? > Like the docstring says > > "Users who wish to avoid evaluating code on export should use the > header argument ‘:eval never-export’." > > It is tempting to `make-obsolete-variable' this variable and change > its name to something that more completely describes what does not > happen when set to nil. It can be done for Org 9.1. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-12 11:00 ` Nicolas Goaziou @ 2016-11-13 3:09 ` Charles C. Berry 2016-11-13 8:02 ` Nicolas Goaziou 0 siblings, 1 reply; 13+ messages in thread From: Charles C. Berry @ 2016-11-13 3:09 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-Mode mailing list [-- Attachment #1: Type: text/plain, Size: 643 bytes --] On Sat, 12 Nov 2016, Nicolas Goaziou wrote: [discussion of problems interpreting the variable `org-export-babel-evaluate' deleted] >> >> It is tempting to `make-obsolete-variable' this variable and change >> its name to something that more completely describes what does not >> happen when set to nil. > > It can be done for Org 9.1. > OK. I changed the name to `org-export-process-with-babel', which I hope suggests more profound actions than `org-export-babel-evaluate'. 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. Chuck [-- Attachment #2: patch file --] [-- Type: text/plain, Size: 14535 bytes --] From 3885129980a02eb0d4694e9e15888dea6ee95c60 Mon Sep 17 00:00:00 2001 From: Charles Berry <ccberry@ucsd.edu> Date: Sat, 12 Nov 2016 18:54:20 -0800 Subject: [PATCH] make-obsolete-variable `org-export-babel-evaluate' * 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. 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 +when Org mode is used as the markup language for a wiki. No header arguments +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. 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) (defmacro org-babel-exp--at-source (&rest body) "Evaluate BODY at the source of the Babel block at point. @@ -128,10 +128,10 @@ this template." (defun org-babel-exp-process-buffer () "Execute all Babel blocks in current buffer." (interactive) - (when org-export-babel-evaluate + (when org-export-process-with-babel (save-window-excursion (let ((case-fold-search t) - (regexp (if (eq org-export-babel-evaluate 'inline-only) + (regexp (if (eq org-export-process-with-babel 'inline-only) "\\(call\\|src\\)_" "\\(call\\|src\\)_\\|^[ \t]*#\\+\\(BEGIN_SRC\\|CALL:\\)")) ;; Get a pristine copy of current buffer so Babel diff --git a/lisp/org-compat.el b/lisp/org-compat.el index 202b728..dc01a48 100644 --- a/lisp/org-compat.el +++ b/lisp/org-compat.el @@ -191,6 +191,8 @@ Counting starts at 1." (define-obsolete-variable-alias 'org-html-style 'org-html-head "24.4") (define-obsolete-function-alias 'org-insert-columns-dblock 'org-columns-insert-dblock "Org 9.0") +(define-obsolete-function-alias 'org-export-babel-evaluate + 'org-export-process-with-babel "Org 9.1") (defun org-in-fixed-width-region-p () "Non-nil if point in a fixed-width region." diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el index c22866a..6a480f4 100644 --- a/lisp/ox-icalendar.el +++ b/lisp/ox-icalendar.el @@ -879,7 +879,7 @@ The file is stored under the name chosen in "Export current agenda view to an iCalendar FILE. This function assumes major mode for current buffer is `org-agenda-mode'." - (let* ((org-export-babel-evaluate) ; Don't evaluate Babel block. + (let* ((org-export-process-with-babel) ; Don't evaluate Babel block. (contents (org-export-string-as (with-output-to-string diff --git a/lisp/ox.el b/lisp/ox.el index ca1143c..d67c56a 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -3042,7 +3042,7 @@ Return code as a string." ;; again after executing Babel code. (org-set-regexps-and-options) (org-update-radio-target-regexp) - (when org-export-babel-evaluate + (when org-export-process-with-babel (org-babel-exp-process-buffer) (org-set-regexps-and-options) (org-update-radio-target-regexp)) diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el index 744234c..e32a03c 100644 --- a/testing/lisp/test-ob-exp.el +++ b/testing/lisp/test-ob-exp.el @@ -29,7 +29,7 @@ Current buffer is a copy of the original buffer." `(let ((string (org-with-wide-buffer (buffer-string))) (narrowing (list (point-min) (point-max))) - (org-export-babel-evaluate t)) + (org-export-process-with-babel t)) (with-temp-buffer (org-mode) (insert string) @@ -183,7 +183,7 @@ a table." (ert-deftest ob-exp/evaluate-all-executables-in-order () (should (equal '(5 4 3 2 1) - (let ((org-export-babel-evaluate t) *evaluation-collector*) + (let ((org-export-process-with-babel t) *evaluation-collector*) (org-test-at-id "96cc7073-97ec-4556-87cf-1f9bffafd317" (org-narrow-to-subtree) (buffer-string) @@ -202,7 +202,7 @@ Here is one at the end of a line. {{{results(=2=)}}} (ert-deftest ob-exp/exports-inline-code () (let ((org-babel-inline-result-wrap "=%s=") - (org-export-babel-evaluate t)) + (org-export-process-with-babel t)) (should (string-match "\\`src_emacs-lisp\\(?:\\[]\\)?{(\\+ 1 1)}$" (org-test-with-temp-text @@ -259,7 +259,7 @@ Here is one that is also evaluated: src_sh[]{echo 4} {{{results(=4=)}}}") results), the resulting code block `src_emacs-lisp{2}' should also be evaluated." (let ((org-babel-inline-result-wrap "=%s=") - (org-export-babel-evaluate t)) + (org-export-process-with-babel t)) (should (string-match "\\`{{{results(src_emacs-lisp\\[\\]{2})}}}$" (org-test-with-temp-text @@ -270,7 +270,7 @@ evaluated." (ert-deftest ob-exp/exports-inline-code-eval-code-once () "Ibid above, except that the resulting inline code block should not be evaluated." - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (should (string-match "{{{results(src_emacs-lisp\\(?:\\[[: a-zA-Z]+]\\)?{2})}}}$" (org-test-with-temp-text @@ -280,7 +280,7 @@ be evaluated." (buffer-string)))))) (ert-deftest ob-exp/exports-inline-code-double-eval-exports-both () - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (should (string-match (concat "\\`src_emacs-lisp\\(?:\\[]\\)?{(\\+ 1 1)} " "{{{results(src_emacs-lisp\\[ :exports code\\]{2})}}}$") @@ -351,7 +351,7 @@ be evaluated." result))))) (ert-deftest ob-exp/export-from-a-temp-buffer () - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (org-test-with-temp-text " #+Title: exporting from a temporary buffer @@ -377,7 +377,7 @@ be evaluated." (ert-deftest ob-export/export-with-results-before-block () "Test export when results are inserted before source block." - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (should (equal "#+RESULTS: src1 @@ -452,7 +452,7 @@ be evaluated." (ert-deftest ob-export/export-under-commented-headline () "Test evaluation of code blocks under COMMENT headings." - (let ((org-export-babel-evaluate t) + (let ((org-export-process-with-babel t) (org-babel-inline-result-wrap "=%s=")) ;; Do not eval block in a commented headline. (should @@ -516,21 +516,21 @@ src_emacs-lisp{(+ 1 1)}" (org-babel-exp-process-buffer) t))) (ert-deftest ob-export/babel-evaluate () - "Test `org-export-babel-evaluate' effect." + "Test `org-export-process-with-babel' effect." ;; When nil, no Babel code is executed. (should-not (string-match-p "2" (org-test-with-temp-text "#+BEGIN_SRC emacs-lisp :exports results\n(+ 1 1)\n#+END_SRC" - (let ((org-export-babel-evaluate nil)) (org-babel-exp-process-buffer)) + (let ((org-export-process-with-babel nil)) (org-babel-exp-process-buffer)) (buffer-string)))) (should-not (string-match-p "2" (org-test-with-temp-text "src_emacs-lisp{(+ 1 1)}" - (let ((org-export-babel-evaluate nil)) (org-babel-exp-process-buffer)) + (let ((org-export-process-with-babel nil)) (org-babel-exp-process-buffer)) (buffer-string)))) ;; When non-nil, all Babel code types are executed. (should @@ -538,14 +538,14 @@ src_emacs-lisp{(+ 1 1)}" "2" (org-test-with-temp-text "#+BEGIN_SRC emacs-lisp :exports results\n(+ 1 1)\n#+END_SRC" - (let ((org-export-babel-evaluate t)) (org-babel-exp-process-buffer)) + (let ((org-export-process-with-babel t)) (org-babel-exp-process-buffer)) (buffer-string)))) (should (string-match-p "2" (org-test-with-temp-text "src_emacs-lisp{(+ 1 1)}" - (let ((org-export-babel-evaluate t)) (org-babel-exp-process-buffer)) + (let ((org-export-process-with-babel t)) (org-babel-exp-process-buffer)) (buffer-string)))) ;; When set to `inline-only' limit evaluation to inline code. (should-not @@ -553,7 +553,7 @@ src_emacs-lisp{(+ 1 1)}" "2" (org-test-with-temp-text "#+BEGIN_SRC emacs-lisp :exports results\n(+ 1 1)\n#+END_SRC" - (let ((org-export-babel-evaluate 'inline-only)) + (let ((org-export-process-with-babel 'inline-only)) (org-babel-exp-process-buffer)) (buffer-string)))) (should @@ -561,7 +561,7 @@ src_emacs-lisp{(+ 1 1)}" "2" (org-test-with-temp-text "src_emacs-lisp{(+ 1 1)}" - (let ((org-export-babel-evaluate 'inline-only)) + (let ((org-export-process-with-babel 'inline-only)) (org-babel-exp-process-buffer)) (buffer-string))))) @@ -571,7 +571,7 @@ src_emacs-lisp{(+ 1 1)}" (equal "#+BEGIN_SRC emacs-lisp\n0 (ref:foo)\n#+END_SRC" (org-test-with-temp-text "#+BEGIN_SRC emacs-lisp :exports code\n0 (ref:foo)\n#+END_SRC" - (let ((org-export-babel-evaluate t) + (let ((org-export-process-with-babel t) (org-coderef-label-format "(ref:foo)")) (org-babel-exp-process-buffer)) (buffer-string)))) @@ -580,7 +580,7 @@ src_emacs-lisp{(+ 1 1)}" "#+BEGIN_SRC emacs-lisp -l \"r:%s\"\n1 r:foo\n#+END_SRC" (org-test-with-temp-text "#+BEGIN_SRC emacs-lisp -l \"r:%s\" -lisp :exports code\n1 r:foo\n#+END_SRC" - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (org-babel-exp-process-buffer)) (buffer-string))))) diff --git a/testing/lisp/test-ob-lob.el b/testing/lisp/test-ob-lob.el index 55a01ef..246cdb7 100644 --- a/testing/lisp/test-ob-lob.el +++ b/testing/lisp/test-ob-lob.el @@ -80,7 +80,7 @@ (ert-deftest test-ob-lob/export-lob-lines () "Test the export of a variety of library babel call lines." (let ((org-babel-inline-result-wrap "=%s=") - (org-export-babel-evaluate t)) + (org-export-process-with-babel t)) (org-test-at-id "72ddeed3-2d17-4c7f-8192-a575d535d3fc" (org-narrow-to-subtree) (let ((string (org-with-wide-buffer (buffer-string))) diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el index 5300f52..7705298 100644 --- a/testing/lisp/test-ox.el +++ b/testing/lisp/test-ox.el @@ -900,7 +900,7 @@ Paragraph <2012-03-29 Thu>[2012-03-29 Thu]" #+BEGIN_SRC emacs-lisp \(+ 1 2) #+END_SRC" - (let ((org-export-babel-evaluate t)) + (let ((org-export-process-with-babel t)) (org-export-as (org-test-default-backend) 'subtree))))) ;; Subtree export should ignore leading planning line and property ;; drawer. -- 2.6.4 (Apple Git-63) ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-13 3:09 ` [PATCH] " Charles C. Berry @ 2016-11-13 8:02 ` Nicolas Goaziou 2016-11-13 23:38 ` Charles C. Berry 0 siblings, 1 reply; 13+ messages in thread From: Nicolas Goaziou @ 2016-11-13 8:02 UTC (permalink / raw) To: Charles C. Berry; +Cc: Org-Mode mailing list Hello, "Charles C. Berry" <ccberry@ucsd.edu> 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 <ccberry@ucsd.edu> > 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-13 8:02 ` Nicolas Goaziou @ 2016-11-13 23:38 ` Charles C. Berry 2016-11-14 7:43 ` Nicolas Goaziou 0 siblings, 1 reply; 13+ messages in thread From: Charles C. Berry @ 2016-11-13 23:38 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: Org-Mode mailing list On Sun, 13 Nov 2016, Nicolas Goaziou wrote: > Hello, > > "Charles C. Berry" <ccberry@ucsd.edu> writes: > [snip] > > 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? > You are right. `org-export-use-babel' it is. Thanks for the suggestions. I pushed them to master just now. Chuck ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-13 23:38 ` Charles C. Berry @ 2016-11-14 7:43 ` Nicolas Goaziou 0 siblings, 0 replies; 13+ messages in thread From: Nicolas Goaziou @ 2016-11-14 7:43 UTC (permalink / raw) To: Charles C. Berry; +Cc: Org-Mode mailing list Hello, "Charles C. Berry" <ccberry@ucsd.edu> writes: > Thanks for the suggestions. I pushed them to master just now. Thank you. Regards, -- Nicolas Goaziou ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-12 3:21 ` Charles C. Berry 2016-11-12 11:00 ` Nicolas Goaziou @ 2016-11-14 13:32 ` Frederick Giasson 1 sibling, 0 replies; 13+ messages in thread From: Frederick Giasson @ 2016-11-14 13:32 UTC (permalink / raw) To: emacs-orgmode Hi Charles, > Setting `org-export-babel-evaluate' to nil will ensure that NONE of > your header arguments are followed. > > Like the docstring says > > "Users who wish to avoid evaluating code on export should use the > header argument ‘:eval never-export’." > > It is tempting to `make-obsolete-variable' this variable and change > its name to something that more completely describes what does not > happen when set to nil. Great, thanks for the clarification! Take care, Fred ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: HTML export with ":export" parameter with Orgmode 9.0 2016-11-11 9:33 ` Nicolas Goaziou 2016-11-11 14:11 ` Frederick Giasson @ 2016-11-11 17:10 ` Frederick Giasson 1 sibling, 0 replies; 13+ messages in thread From: Frederick Giasson @ 2016-11-11 17:10 UTC (permalink / raw) To: emacs-orgmode Hi Nicolas, > It seems other users experienced it, yet it is unexpected and I cannot > reproduce it even with a minimal init file. Ok I think I found the issue. In all the files I worked on since I upgraded to 9.0 I had the following setting at the top of my org files: ========= # -*- org-export-babel-evaluate: nil -*- ========= In these notebooks, I don't want org-export to evaluate the code blocks, I want to do it manually (since some of them takes quite a while to run and I don't want to wait minutes to get an export). In 8.x this was working perfectly. However, it appears that this behavior changed in 9.0. If I have that in place, then the :export header parameter is basically ignored and defaulted to "both". Did this change and is this to be expected? If so, what should I use to get the same behavior? Thanks! Fred > > Regards, > ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-11-14 13:33 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-11-08 13:30 HTML export with ":export" parameter with Orgmode 9.0 Frederick Giasson 2016-11-11 9:33 ` Nicolas Goaziou 2016-11-11 14:11 ` Frederick Giasson 2016-11-11 17:21 ` Charles C. Berry 2016-11-11 18:15 ` Frederick Giasson 2016-11-12 3:21 ` Charles C. Berry 2016-11-12 11:00 ` Nicolas Goaziou 2016-11-13 3:09 ` [PATCH] " Charles C. Berry 2016-11-13 8:02 ` Nicolas Goaziou 2016-11-13 23:38 ` Charles C. Berry 2016-11-14 7:43 ` Nicolas Goaziou 2016-11-14 13:32 ` Frederick Giasson 2016-11-11 17:10 ` Frederick Giasson
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).