* 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 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
* 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
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).