Hi Eric, Eric S Fraga <e.fr...@ucl.ac.uk> writes:
> Nick Dokos <nicholas.do...@hp.com> writes: > > [...] > >> Good question (I mean the *How* question): I believe this is a bug and >> it has to do with the problem that Dan Davison identified and (as it >> turns out) partially fixed a year ago (see >> http://thread.gmane.org/gmane.emacs.orgmode/35439/focus=36878 for those >> details). >> >> In a nutshell, the problem is that many export operations happen in >> temporary buffers. These buffers do not automatically inherit local > > [...] > > Nick, > > Many thanks for this analysis. My gut feeling was indeed correct > (whew!), probably because I subconsciously remembered reading the thread > from Dan Davison. > >> The quick-and-dirty hack would be to call Dan's cloning function in the >> call to with-temp-buffer, but that's not enough: >> org-export-latex-fontify-headline does the temp-buffer thingie as well >> and needs the same treatment. That seems to make *this* case work but I'm >> almost 100% sure that that won't be enough in the general case either: >> there are probably other places where temp buffers are created to do >> some processing like this. They will also be subject to this problem. > > I must admit I am confused as to the point of #+BIND now. I had thought > the whole purpose was to set variables to be used during the export > process but now it seems this is not the case. Or it is only the case > for some subset of the variables that may affect the export process. > > I don't care whether I need to use file local variables, #+BIND, or any > other mechanism but it would be nice to have some mechanism! So, can > anybody suggest any hack around this problem? I am not terribly worried > about this as it only causes me difficulties now and again when I have a > specific type of document I need to generate for > dissemination. Usually, my default settings are fine. However, it > would be nice to have some solution to this. > > I can have an emacs lisp code block which gets executed to set > the values of those variables. This works (see attachment), so long as > I don't have any other controls for settings these variables, including > file local variables or #+BIND. However, I need to manually execute > this code block if it is hidden away in a not-exported region of the > document. Otherwise, it clogs up the text (but such is life!). > > Note, however, that this changes the variable value globally and so will > affect exporting of any other subsequent org documents unless they have > their own settings. Not *good* but good enough for my own use case for > the moment... and, actually, having explicit settings for export > variables in every *important* document is probably not a bad > idea. Ummm, need to think about this. If you (and the receiver) tangle your export-settings source code block to init.el (:tangle init.el), then execute something like the following source code block #+begin_src sh emacs -Q -l init.el examplebug.org #+end_src you should be able to ensure that the receiver will get the same result you get. Of course, anything in your .emacs (or other initialization files) that is needed to produce the results will need to be included in export-settings. hth, Tom > > > #+TITLE: examplebug.org > #+AUTHOR: Eric S Fraga > #+EMAIL: e.fr...@ucl.ac.uk > #+DATE: 2012-01-09 Mon > > * Formatting tags :example: > When exporting, the default is to put tags in bold. I want a box around > them. > > > # the following is used to set some variables which affect export to latex > #+name: export-settings > #+begin_src emacs-lisp :exports results :results silent > (setq org-export-latex-tag-markup "babel: \\fbox{%s}") > #+end_src > > > > Anyway, thanks again, > eric -- Thomas S. Dye http://www.tsdye.com
