org-export-current-backend variable and org-mode 8

org-export-current-backend variable and org-mode 8

[Christophe Rhodes]

Hi,

In org-mode 7, I was able to use the (documented) variable
org-export-current-backend to test what the current backend is, allowing
me to dynamically produce and include images of different formats
depending on whether I was exporting to latex (tikz) or html (png).

In org-mode 8, I cannot find this variable, or any documented variable
of a similar nature.  What is the recommended way for dispatching at the
emacs-lisp level when exporting a document on the export backend?

Thanks,

Christophe

Re: org-export-current-backend variable and org-mode 8

[Brett Viren]

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

Hi Christophe,

Christophe Rhodes <csr21@cantab.net> writes:

> In org-mode 7, I was able to use the (documented) variable
> org-export-current-backend to test what the current backend is, allowing
> me to dynamically produce and include images of different formats
> depending on whether I was exporting to latex (tikz) or html (png).
>
> In org-mode 8, I cannot find this variable, or any documented variable
> of a similar nature.  What is the recommended way for dispatching at the
> emacs-lisp level when exporting a document on the export backend?

I don't know if this is exactly what you are asking for but I hit on the
following a few weeks ago.  It defines an elisp macro inside the org
file and then calls it later in the header of a code block to switch the
output file names based on which backend (if any) is in effect.  I hope
it helps.

If you have a better way to do these kind of output switches, I'd like
to know.


* COMMENT setup

#+begin_src emacs-lisp :results silent
  (defmacro by-backend (&rest body)
    `(case (if (boundp 'backend) backend nil) ,@body))
#+end_src
  
* A graph

#+header: :file (by-backend (html "graph.png") (latex "graph.pdf") (t "graph.svg"))
#+header: :export results
#+begin_src dot
digraph Name {
        tail -> head;
}
#+end_src


-Brett.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: org-export-current-backend variable and org-mode 8

[Christophe Rhodes]

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

Brett Viren <bv@bnl.gov> writes:

> Christophe Rhodes <csr21@cantab.net> writes:
>
>> In org-mode 7, I was able to use the (documented) variable
>> org-export-current-backend to test what the current backend is, allowing
>> me to dynamically produce and include images of different formats
>> depending on whether I was exporting to latex (tikz) or html (png).
>>
>> In org-mode 8, I cannot find this variable, or any documented variable
>> of a similar nature.  What is the recommended way for dispatching at the
>> emacs-lisp level when exporting a document on the export backend?
>
> I don't know if this is exactly what you are asking for but I hit on the
> following a few weeks ago.  It defines an elisp macro inside the org
> file and then calls it later in the header of a code block to switch the
> output file names based on which backend (if any) is in effect.  I hope
> it helps.

Thanks.  Well, it proves at least that I'm not going mad :-(

> If you have a better way to do these kind of output switches, I'd like
> to know.

> #+begin_src emacs-lisp :results silent
>   (defmacro by-backend (&rest body)
>     `(case (if (boundp 'backend) backend nil) ,@body))
> #+end_src

It's funny -- I felt queasy using the bare backend variable in the olden
6.x days, and was very happy when org-export-current-backend showed up.
Now, there's a real reason to be worried about using backend: it's
fairly clearly used as an internal variable, and all it would take would
be for lexical binding to be turned on for ox.el and this would
(probably) stop working.

If we're grubbing around in internals, I might be tempted instead by
something like [untested]

#+begin_src emacs-lisp :exports results :results silent
  (unless (boundp 'org-export-current-backend)
    (defadvice org-export-as (around oecb-around)
      (let ((org-export-current-backend (ad-get-arg 0)))
        ad-do-it)))
#+end_src

so that if (as I hope) org-export-current-backend makes a later
reappearance, my documents can work with both org-mode 7 and 8, and
maybe 9?  I'm hoping that the disappearance of the variable is an
oversight rather than intentional :-/

Cheers,

Christophe

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: org-export-current-backend variable and org-mode 8

[Nicolas Goaziou]

Hello,

Christophe Rhodes <csr21@cantab.net> writes:

> so that if (as I hope) org-export-current-backend makes a later
> reappearance, my documents can work with both org-mode 7 and 8, and
> maybe 9?  I'm hoping that the disappearance of the variable is an
> oversight rather than intentional :-/

It is intentional. I tried to reduce the number of dynamically scoped
variables.

On the other hand, hooks and filters all get back-end's name, if any, as
an argument, which limits the need for that variable. The only missing
part is Babel. I thought the recently introduced `by-backend' feature
was sufficient. Isn't it the case?

I also thought about reintroducing `org-export-current-backend', but
that would be redundant with hooks and filters' arguments. Removing
these is not an option either, as that would break every hook/filter in
the wild.


Regards,

-- 
Nicolas Goaziou

Re: org-export-current-backend variable and org-mode 8

[Christophe Rhodes]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Christophe Rhodes <csr21@cantab.net> writes:
>
>> so that if (as I hope) org-export-current-backend makes a later
>> reappearance, my documents can work with both org-mode 7 and 8, and
>> maybe 9?  I'm hoping that the disappearance of the variable is an
>> oversight rather than intentional :-/
>
> It is intentional. I tried to reduce the number of dynamically scoped
> variables.
>
> On the other hand, hooks and filters all get back-end's name, if any, as
> an argument, which limits the need for that variable. The only missing
> part is Babel. I thought the recently introduced `by-backend' feature
> was sufficient. Isn't it the case?

The `by-backend' macro in Brett Viren's message upthread?  Personally I
don't consider that sufficient, because it feels very fragile: a simple
renaming of org-mode internal variables, or turning on lexical binding,
and the macro will no longer work.  (If you mean some other
`by-backend', I haven't seen it).

In particular, I would like to have some kind of confidence that
documents that I wrote last year will still be exportable next year with
only minor modifications necessary, and to do that I think I need to
convince you that this is valuable, enough that you are willing to
commit to some stable way of accessing the information previously held
in org-export-current-backend.

> I also thought about reintroducing `org-export-current-backend', but
> that would be redundant with hooks and filters' arguments. Removing
> these is not an option either, as that would break every hook/filter in
> the wild.

Please don't remove hooks and filters, or change their arguments!  But
please consider reintroducing org-export-current-backend; I have just
checked, and the document that I am currently editing exports to latex
and html unmodified from the org-mode 7 version, apart from some trivial
variable renamings in the elisp setup and the reintroduction through
advice of org-export-current-backend.  And although that's fairly
straightforward for me to achieve, it's a cost, and one that I have to
pay every time I want to share a reproducible research document with a
colleague who hasn't upgraded to org-mode 8 yet, maybe because some of
/their/ documents don't yet build under org-mode 8...

Best wishes,

Christophe

Re: org-export-current-backend variable and org-mode 8

[Christophe Rhodes]

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

Christophe Rhodes <csr21@cantab.net> writes:

> The `by-backend' macro in Brett Viren's message upthread?  Personally I
> don't consider that sufficient, because it feels very fragile: a simple
> renaming of org-mode internal variables, or turning on lexical binding,
> and the macro will no longer work.  (If you mean some other
> `by-backend', I haven't seen it).
>
> In particular, I would like to have some kind of confidence that
> documents that I wrote last year will still be exportable next year with
> only minor modifications necessary, and to do that I think I need to
> convince you that this is valuable, enough that you are willing to
> commit to some stable way of accessing the information previously held
> in org-export-current-backend.

Attempting to put my money where my mouth is: find attached a patch to
restore org-export-current-backend.  I think this is a TINYCHANGE
despite the large diff -- it's almost all whitespace, and the docstring
is restored verbatim from org-mode 7.9 (I haven't updated it for the
removal of the docbook backend, for example, primarily so that it has
minimal novel information in it).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-restore-org-export-current-backend-variable.patch --]
[-- Type: text/x-diff, Size: 10636 bytes --]

From 29d11fdda3b8302d437fdb309c195aa9e806505d Mon Sep 17 00:00:00 2001
From: Christophe Rhodes <c.rhodes@gold.ac.uk>
Date: Fri, 2 Aug 2013 10:56:37 +0100
Subject: [PATCH] ox: restore org-export-current-backend variable

* lisp/ox.el (org-export-current-backend): new variable.
(org-export-as): bind it.

TINYCHANGE
---
 lisp/ox.el |  214 +++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 111 insertions(+), 103 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 5d28a81..8962428 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -290,6 +290,13 @@ and its CDR is a list of export options.")
 This marker will be used with `C-u C-c C-e' to make sure export repetition
 uses the same subtree if the previous command was restricted to a subtree.")
 
+(defvar org-export-current-backend nil
+  "During export, this will be bound to a symbol such as 'html,
+  'latex, 'docbook, 'ascii, etc, indicating which of the export
+  backends is in use.  Otherwise it has the value nil.  Users
+  should not attempt to change the value of this variable
+  directly, but it can be used in code to test whether export is
+  in progress, and if so, what the backend is.")
 \f
 ;;; User-configurable Variables
 ;;
@@ -2947,109 +2954,110 @@ still inferior to file-local settings.
 Return code as a string."
   (when (symbolp backend) (setq backend (org-export-get-backend backend)))
   (org-export-barf-if-invalid-backend backend)
-  (save-excursion
-    (save-restriction
-      ;; Narrow buffer to an appropriate region or subtree for
-      ;; parsing.  If parsing subtree, be sure to remove main headline
-      ;; too.
-      (cond ((org-region-active-p)
-	     (narrow-to-region (region-beginning) (region-end)))
-	    (subtreep
-	     (org-narrow-to-subtree)
-	     (goto-char (point-min))
-	     (forward-line)
-	     (narrow-to-region (point) (point-max))))
-      ;; Initialize communication channel with original buffer
-      ;; attributes, unavailable in its copy.
-      (let* ((info (org-combine-plists
-		    (list :export-options
-			  (delq nil
-				(list (and subtreep 'subtree)
-				      (and visible-only 'visible-only)
-				      (and body-only 'body-only))))
-		    (org-export--get-buffer-attributes)))
-	     tree)
-	;; Store default title in `org-export--default-title' so that
-	;; `org-export-get-environment' can access it from buffer's
-	;; copy and then add it properly to communication channel.
-	(org-export-store-default-title)
-	;; Update communication channel and get parse tree.  Buffer
-	;; isn't parsed directly.  Instead, a temporary copy is
-	;; created, where include keywords, macros are expanded and
-	;; code blocks are evaluated.
-	(org-export-with-buffer-copy
-	 ;; Run first hook with current back-end's name as argument.
-	 (run-hook-with-args 'org-export-before-processing-hook
-			     (org-export-backend-name backend))
-	 (org-export-expand-include-keyword)
-	 ;; Update macro templates since #+INCLUDE keywords might have
-	 ;; added some new ones.
-	 (org-macro-initialize-templates)
-	 (org-macro-replace-all org-macro-templates)
-	 (org-export-execute-babel-code)
-	 ;; Update radio targets since keyword inclusion might have
-	 ;; added some more.
-	 (org-update-radio-target-regexp)
-	 ;; Run last hook with current back-end's name as argument.
-	 (goto-char (point-min))
-	 (save-excursion
-	   (run-hook-with-args 'org-export-before-parsing-hook
-			       (org-export-backend-name backend)))
-	 ;; Update communication channel with environment.  Also
-	 ;; install user's and developer's filters.
-	 (setq info
-	       (org-export-install-filters
-		(org-combine-plists
-		 info (org-export-get-environment backend subtreep ext-plist))))
-	 ;; Expand export-specific set of macros: {{{author}}},
-	 ;; {{{date}}}, {{{email}}} and {{{title}}}.  It must be done
-	 ;; once regular macros have been expanded, since document
-	 ;; keywords may contain one of them.
-	 (org-macro-replace-all
-	  (list (cons "author"
-		      (org-element-interpret-data (plist-get info :author)))
-		(cons "date"
-		      (org-element-interpret-data (plist-get info :date)))
-		;; EMAIL is not a parsed keyword: store it as-is.
-		(cons "email" (or (plist-get info :email) ""))
-		(cons "title"
-		      (org-element-interpret-data (plist-get info :title)))))
-	 ;; Call options filters and update export options.  We do not
-	 ;; use `org-export-filter-apply-functions' here since the
-	 ;; arity of such filters is different.
-	 (let ((backend-name (org-export-backend-name backend)))
-	   (dolist (filter (plist-get info :filter-options))
-	     (let ((result (funcall filter info backend-name)))
-	       (when result (setq info result)))))
-	 ;; Parse buffer and call parse-tree filter on it.
-	 (setq tree
-	       (org-export-filter-apply-functions
-		(plist-get info :filter-parse-tree)
-		(org-element-parse-buffer nil visible-only) info))
-	 ;; Now tree is complete, compute its properties and add them
-	 ;; to communication channel.
-	 (setq info
-	       (org-combine-plists
-		info (org-export-collect-tree-properties tree info)))
-	 ;; Eventually transcode TREE.  Wrap the resulting string into
-	 ;; a template.
-	 (let* ((body (org-element-normalize-string
-		       (or (org-export-data tree info) "")))
-		(inner-template (cdr (assq 'inner-template
-					   (plist-get info :translate-alist))))
-		(full-body (if (not (functionp inner-template)) body
-			     (funcall inner-template body info)))
-		(template (cdr (assq 'template
-				     (plist-get info :translate-alist)))))
-	   ;; Remove all text properties since they cannot be
-	   ;; retrieved from an external process.  Finally call
-	   ;; final-output filter and return result.
-	   (org-no-properties
-	    (org-export-filter-apply-functions
-	     (plist-get info :filter-final-output)
-	     (if (or (not (functionp template)) body-only) full-body
-	       (funcall template full-body info))
-	     info))))))))
+  (let ((org-export-current-backend backend))
+    (save-excursion
+      (save-restriction
+	;; Narrow buffer to an appropriate region or subtree for
+	;; parsing.  If parsing subtree, be sure to remove main headline
+	;; too.
+	(cond ((org-region-active-p)
+	       (narrow-to-region (region-beginning) (region-end)))
+	      (subtreep
+	       (org-narrow-to-subtree)
+	       (goto-char (point-min))
+	       (forward-line)
+	       (narrow-to-region (point) (point-max))))
+	;; Initialize communication channel with original buffer
+	;; attributes, unavailable in its copy.
+	(let* ((info (org-combine-plists
+		      (list :export-options
+			    (delq nil
+				  (list (and subtreep 'subtree)
+					(and visible-only 'visible-only)
+					(and body-only 'body-only))))
+		      (org-export--get-buffer-attributes)))
+	       tree)
+	  ;; Store default title in `org-export--default-title' so that
+	  ;; `org-export-get-environment' can access it from buffer's
+	  ;; copy and then add it properly to communication channel.
+	  (org-export-store-default-title)
+	  ;; Update communication channel and get parse tree.  Buffer
+	  ;; isn't parsed directly.  Instead, a temporary copy is
+	  ;; created, where include keywords, macros are expanded and
+	  ;; code blocks are evaluated.
+	  (org-export-with-buffer-copy
+	   ;; Run first hook with current back-end's name as argument.
+	   (run-hook-with-args 'org-export-before-processing-hook
+			       (org-export-backend-name backend))
+	   (org-export-expand-include-keyword)
+	   ;; Update macro templates since #+INCLUDE keywords might have
+	   ;; added some new ones.
+	   (org-macro-initialize-templates)
+	   (org-macro-replace-all org-macro-templates)
+	   (org-export-execute-babel-code)
+	   ;; Update radio targets since keyword inclusion might have
+	   ;; added some more.
+	   (org-update-radio-target-regexp)
+	   ;; Run last hook with current back-end's name as argument.
+	   (goto-char (point-min))
+	   (save-excursion
+	     (run-hook-with-args 'org-export-before-parsing-hook
+				 (org-export-backend-name backend)))
+	   ;; Update communication channel with environment.  Also
+	   ;; install user's and developer's filters.
+	   (setq info
+		 (org-export-install-filters
+		  (org-combine-plists
+		   info (org-export-get-environment backend subtreep ext-plist))))
+	   ;; Expand export-specific set of macros: {{{author}}},
+	   ;; {{{date}}}, {{{email}}} and {{{title}}}.  It must be done
+	   ;; once regular macros have been expanded, since document
+	   ;; keywords may contain one of them.
+	   (org-macro-replace-all
+	    (list (cons "author"
+			(org-element-interpret-data (plist-get info :author)))
+		  (cons "date"
+			(org-element-interpret-data (plist-get info :date)))
+		  ;; EMAIL is not a parsed keyword: store it as-is.
+		  (cons "email" (or (plist-get info :email) ""))
+		  (cons "title"
+			(org-element-interpret-data (plist-get info :title)))))
+	   ;; Call options filters and update export options.  We do not
+	   ;; use `org-export-filter-apply-functions' here since the
+	   ;; arity of such filters is different.
+	   (let ((backend-name (org-export-backend-name backend)))
+	     (dolist (filter (plist-get info :filter-options))
+	       (let ((result (funcall filter info backend-name)))
+		 (when result (setq info result)))))
+	   ;; Parse buffer and call parse-tree filter on it.
+	   (setq tree
+		 (org-export-filter-apply-functions
+		  (plist-get info :filter-parse-tree)
+		  (org-element-parse-buffer nil visible-only) info))
+	   ;; Now tree is complete, compute its properties and add them
+	   ;; to communication channel.
+	   (setq info
+		 (org-combine-plists
+		  info (org-export-collect-tree-properties tree info)))
+	   ;; Eventually transcode TREE.  Wrap the resulting string into
+	   ;; a template.
+	   (let* ((body (org-element-normalize-string
+			 (or (org-export-data tree info) "")))
+		  (inner-template (cdr (assq 'inner-template
+					     (plist-get info :translate-alist))))
+		  (full-body (if (not (functionp inner-template)) body
+			       (funcall inner-template body info)))
+		  (template (cdr (assq 'template
+				       (plist-get info :translate-alist)))))
+	     ;; Remove all text properties since they cannot be
+	     ;; retrieved from an external process.  Finally call
+	     ;; final-output filter and return result.
+	     (org-no-properties
+	      (org-export-filter-apply-functions
+	       (plist-get info :filter-final-output)
+	       (if (or (not (functionp template)) body-only) full-body
+		 (funcall template full-body info))
+	       info)))))))))
 
 ;;;###autoload
 (defun org-export-to-buffer
-- 
1.7.10.4


[-- Attachment #3: Type: text/plain, Size: 26 bytes --]


Best wishes,

Christophe

Re: org-export-current-backend variable and org-mode 8

[Nicolas Goaziou]

Hello,

Christophe Rhodes <csr21@cantab.net> writes:

>> The `by-backend' macro in Brett Viren's message upthread?  Personally I
>> don't consider that sufficient, because it feels very fragile: a simple
>> renaming of org-mode internal variables, or turning on lexical binding,
>> and the macro will no longer work.  (If you mean some other
>> `by-backend', I haven't seen it).

I thought `by-backend' was in core already. Anyway, if it is, we'll make
sure it will not be fragile anymore.

> Subject: [PATCH] ox: restore org-export-current-backend variable
>
> * lisp/ox.el (org-export-current-backend): new variable.
> (org-export-as): bind it.

Applied a slightly different version. Thank you.


Regards,

-- 
Nicolas Goaziou

Re: org-export-current-backend variable and org-mode 8

[Achim Gratz]

Nicolas Goaziou writes:
> Applied a slightly different version. Thank you.

Shouldn't d1d918100e be in maint?

Also, I don't think that "nil" should mean both "export in progress with
an anonymous backend" and "no export in progress".  You've been
advertising the use of anonmous derived backends to customize exporting,
so to me it would make more sense if somehow there was a way to detect
that situation and then get the name of the parent backend instead.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: org-export-current-backend variable and org-mode 8

[Nicolas Goaziou]

Hello,

Achim Gratz <Stromeko@nexgo.de> writes:

> Nicolas Goaziou writes:
>> Applied a slightly different version. Thank you.
>
> Shouldn't d1d918100e be in maint?

No. Back-end as defstructs is only in the "master" branch.

> Also, I don't think that "nil" should mean both "export in progress with
> an anonymous backend" and "no export in progress".  You've been
> advertising the use of anonmous derived backends to customize exporting,
> so to me it would make more sense if somehow there was a way to detect
> that situation and then get the name of the parent backend instead.

A back-end, anonymous or not, may have no parent at all.

We can also store the full back-end object instead of its name. In this
case, an unnamed back-end is not the same as nil. Alas, this variable
was introduced for compatibility, which that solution kinda defeats.

Speaking about compatibility, previous export framework didn't have
anonymous back-ends. Handling the "nil" case would give us nothing more.


Regards,

-- 
Nicolas Goaziou