From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Variable settings in .emacs VS cross device portability. Date: Wed, 01 Feb 2012 15:37:44 -0500 Message-ID: <3156.1328128664@alphaville> References: <87k448y9gp.fsf@gmx.com> <87ehuf4rar.fsf@ucl.ac.uk> <877h06twg3.fsf@ucl.ac.uk> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:59342) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsgwK-0008EF-F6 for emacs-orgmode@gnu.org; Wed, 01 Feb 2012 15:38:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsgwI-0006sB-TR for emacs-orgmode@gnu.org; Wed, 01 Feb 2012 15:38:00 -0500 Received: from g1t0026.austin.hp.com ([15.216.28.33]:28148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsgwI-0006qt-Nu for emacs-orgmode@gnu.org; Wed, 01 Feb 2012 15:37:58 -0500 Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 0AE27C16A for ; Wed, 1 Feb 2012 20:37:45 +0000 (UTC) In-Reply-To: Message from Eric S Fraga of "Wed, 01 Feb 2012 15:17:16 GMT." <877h06twg3.fsf@ucl.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: org-mode mailing list Cc: nicholas.dokos@hp.com Eric S Fraga wrote: > Hello all, > > herewith is a minimal example that illustrates the problem I have with > exporting and file local variables. The attached file re-defines > org-export-latex-tag-markup to use a box instead of bold for tags. When > I visit the file, Emacs does indeed set the variable to what I > want. However, this setting is ignored on export. > > Actually, in this case, the BIND is also ignored on export even though > the variable does change to the specified value after export! > > I am very confused, to say the least. *How* can I get file local > behaviour when exporting with org? Am I doing something silly > somewhere? (highly likely given my past track record ;-) Do others see > different behaviour? > 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 variables, so the global setting is in force. Dan introduced a "clone local variables" function and arranged for it to be called in org-export-preprocess-string. However, the latter function operates on a temp buffer, so when it returns (it returns the contents of the temp buffer as as a string), the buffer is gone - and so are the local variables. The latex exporter then continues mucking around with the returned string. The org-export-latex-markup variable is used in the function org-export-latex-keywords-maybe. At the relevant moment, the call stack looks like this: ,---- | org-export-latex-keywords-maybe() | org-export-latex-fontify-headline(#(" Formatting tags :example:" 1 16 ...)) | org-export-latex-subcontent(...) | org-export-latex-sub(...) | org-export-latex-global(...) | (let* (...) (set-buffer buffer) (erase-buffer) (org-install-letbind) ... (org-export-latex-global (with-temp-buffer (insert string-for-export)) ...) ...) | org-export-as-latex(nil nil nil "*Org LaTeX Export*") | org-export-as-latex-to-buffer(nil) | call-interactively(org-export-as-latex-to-buffer) `---- Note that org-export-latex-global is called with a temp buffer and neither it nor any of its successors clones local variables. So you end up in org-export-latex-keywords-maybe with the global settings in force. 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. Nick > I'm up to date (as of this morning) with org and latest emacs as of last > week. > > Thanks, > eric > > > > -- > : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 > : using Org-mode version 7.8.03 (release_7.8.03.285.g646b3)