[new exporter] is #+bind supported?

[new exporter] is #+bind supported?

[Eric S Fraga]

Hello,

I seem to have some problem with the new exporter taking into account a
=#+BIND= directive such as

  #+bind: org-latex-pdf-process ("pdflatex %b" "bibtex %b" "pdflatex %b" "pdflatex %b")

Am I doing something really silly here?  I need bibtex to export my org
paper to PDF.  This used to work...

Also, what is the difference between =org-latex-pdf-process= and
=org-latex-to-pdf-process= (note the extra -to in the latter)?  One is
defined in ox-latex and the other in org-latex.

Thanks,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1315-g25b5ab

Re: [new exporter] is #+bind supported?

[Achim Gratz]

Eric S Fraga <e.fraga <at> ucl.ac.uk> writes:
> Also, what is the difference between =org-latex-pdf-process= and
> =org-latex-to-pdf-process= (note the extra -to in the latter)?  One is
> defined in ox-latex and the other in org-latex.

"These are not the droids you were searching for."

Nothing defined in the old exporter should be used with the new one.  The danger
is that some of this stuff will autoload parts of the old exporter and
potentially wreak serious havoc.


Regards,
Achim.

Re: [new exporter] is #+bind supported?

[Eric S Fraga]

Achim Gratz <Stromeko@NexGo.DE> writes:

> Eric S Fraga <e.fraga <at> ucl.ac.uk> writes:
>> Also, what is the difference between =org-latex-pdf-process= and
>> =org-latex-to-pdf-process= (note the extra -to in the latter)?  One is
>> defined in ox-latex and the other in org-latex.
>
> "These are not the droids you were searching for."
>
> Nothing defined in the old exporter should be used with the new one.  The danger
> is that some of this stuff will autoload parts of the old exporter and
> potentially wreak serious havoc.
>
>
> Regards,
> Achim.

Thanks Achim.  My mistake.  The org-latex file is distributed with Emacs
24.3 and obviously was picked up automatically when I looked for
suitable variables (C-h v with tab completion, as apropos never seems to
find anything useful for me) to set.

It is rather annoying to have the old org files picked up
automatically.  My git copy of org-mode is before anything else in my
=load-path= variable.  I know there has been a whole thread on the list
about this but I did not see any solution to this; did I miss one?  I
track emacs-snapshot weekly and org-mode more frequently.

My question still stands in that binding org-latex-pdf-process, which
comes from ox-latex.el, does not appear to work for me.

I do have org-export-allow-bind-keywords set to t but this seems to have
no effect.

Thanks again,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: [new exporter] is #+bind supported?

[Achim Gratz]

Eric S Fraga writes:
> It is rather annoying to have the old org files picked up
> automatically.  My git copy of org-mode is before anything else in my
> =load-path= variable.  I know there has been a whole thread on the list
> about this but I did not see any solution to this; did I miss one?  I
> track emacs-snapshot weekly and org-mode more frequently.

No, nothing complete yet.  Here's what I have so far, some autoload
definitions might still be there, but will error out due to the fact
that their target files are not in load-path anymore.

--8<---------------cut here---------------start------------->8---
;;
;; Kill our ancestors
;;

;; clean load-path
(setq load-path
      (delq nil (mapcar
		 (function (lambda (p)
			     (unless (string-match "lisp/org$" p)
			       p))
			   load-path)))
;; remove property list to defeat cus-load and remove autoloads
(mapatoms (function  (lambda (s)
		       (let ((sn (symbol-name s)))
			 (when (string-match "^\\(org\\|ob\\)-?" sn)
			   (setplist s nil)
			   (when (autoloadp s)
			     (unintern s)))))))
(add-to-list 'load-path "/path/to/org-master")
(load "org-loaddefs.el" nil nil 'nosuffix)
--8<---------------cut here---------------end--------------->8---

I still need to generate the custom-load definitions with the build
system so that you can browse customize without loading all Org files
first.


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

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: [new exporter] is #+bind supported?

[Eric S Fraga]

Achim Gratz <Stromeko@nexgo.de> writes:


[...]

> No, nothing complete yet.  Here's what I have so far, some autoload
> definitions might still be there, but will error out due to the fact
> that their target files are not in load-path anymore.

Thanks for this.  I've incorporated it into my emacs startup.  It should
help!
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: [new exporter] is #+bind supported?

[Achim Gratz]

Eric S Fraga writes:
>> No, nothing complete yet.  Here's what I have so far, some autoload
>> definitions might still be there, but will error out due to the fact
>> that their target files are not in load-path anymore.
>
> Thanks for this.  I've incorporated it into my emacs startup.  It should
> help!

I name you the official tester for this code. :-)

Please keep in mind that the assumption is that no actual Org code has
been loaded, eg. no symbols starting with "ob-" or "org-" would be
features.  So you need to do this very early in the startup sequence.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [new exporter] is #+bind supported?

[Eric S Fraga]

Achim Gratz <Stromeko@nexgo.de> writes:

> Eric S Fraga writes:
>>> No, nothing complete yet.  Here's what I have so far, some autoload
>>> definitions might still be there, but will error out due to the fact
>
>>> that their target files are not in load-path anymore.
>>
>> Thanks for this.  I've incorporated it into my emacs startup.  It should
>> help!
>
> I name you the official tester for this code. :-)

An honour! ;-)

> Please keep in mind that the assumption is that no actual Org code has
> been loaded, eg. no symbols starting with "ob-" or "org-" would be
> features.  So you need to do this very early in the startup sequence.

Yes, this was understood.  I have put your suggested code very early on
in my initialisation, well before anything is loaded beyond the usual
Emacs startup outside my control.

However, my attempt to use this caused problems with Emacs starting
up.  I had too many things to do yesterday to investigate properly so I
commented the code out. I will try again later to see what is happening.
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: [new exporter] is #+bind supported?

[Nicolas Goaziou]

Hello,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> I seem to have some problem with the new exporter taking into account a
> =#+BIND= directive such as
>
>   #+bind: org-latex-pdf-process ("pdflatex %b" "bibtex %b" "pdflatex %b" "pdflatex %b")
>
> Am I doing something really silly here?  I need bibtex to export my org
> paper to PDF.  This used to work...

Bind keywords are supported. Unfortunately, `org-latex-pdf-process' is
not bind-able.

BIND variables are set as buffer-local variables in the buffer where the
transcoding takes place. So, they affect the way the current buffer is
changed into LaTeX code.

However, `org-latex-pdf-process' is used during post-processing, i.e.
after transcoding is over. At this time, the buffer where local
variables were set has disappeared already.

If you need to change the value of `org-latex-pdf-process', use a file
local variable in the current buffer instead.


Regards,

-- 
Nicolas Goaziou

Re: [new exporter] is #+bind supported?

[Eric S Fraga]

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

[...]

> Bind keywords are supported. Unfortunately, `org-latex-pdf-process' is
> not bind-able.
>
> BIND variables are set as buffer-local variables in the buffer where the
> transcoding takes place. So, they affect the way the current buffer is
> changed into LaTeX code.
>
> However, `org-latex-pdf-process' is used during post-processing, i.e.
> after transcoding is over. At this time, the buffer where local
> variables were set has disappeared already.

Okay, I see how this works.  Thanks for the explanation.  Would it not
be possible to set the bound variables for the latex buffer as well?  Or
does that open up a can of worms?  Just curious.

> If you need to change the value of `org-latex-pdf-process', use a file
> local variable in the current buffer instead.

Yes, that works.  I prefer bind as it doesn't clutter up my emacs
customisation with listings of "safe" local variables but so be it.

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3f-1199-g3a0e55

Re: [new exporter] is #+bind supported?

[Nicolas Goaziou]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
> [...]
>
>> Bind keywords are supported. Unfortunately, `org-latex-pdf-process' is
>> not bind-able.
>>
>> BIND variables are set as buffer-local variables in the buffer where the
>> transcoding takes place. So, they affect the way the current buffer is
>> changed into LaTeX code.
>>
>> However, `org-latex-pdf-process' is used during post-processing, i.e.
>> after transcoding is over. At this time, the buffer where local
>> variables were set has disappeared already.
>
> Okay, I see how this works.  Thanks for the explanation.  Would it not
> be possible to set the bound variables for the latex buffer as well?  Or
> does that open up a can of worms?  Just curious.

There is no latex buffer. Export produces a string. Whet it is complete,
the current buffer is the original buffer from which the original
command was issued.

IOW, what you suggest means that BIND keywords should set local
variables in the original buffer. I'm not sure it is the intended goal
for these keywords.

If you need to set a local buffer variable, it is better to use the
dedicated tools.


Regards,

-- 
Nicolas Goaziou