From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Problems with buffer-local variables Date: Wed, 22 Dec 2010 14:51:45 +0000 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from [140.186.70.92] (port=57439 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PVQ2u-0005dx-E6 for emacs-orgmode@gnu.org; Wed, 22 Dec 2010 09:52:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PVQ2t-0005d8-9D for emacs-orgmode@gnu.org; Wed, 22 Dec 2010 09:52:04 -0500 Received: from lo.gmane.org ([80.91.229.12]:60951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PVQ2s-0005ct-UD for emacs-orgmode@gnu.org; Wed, 22 Dec 2010 09:52:03 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PVQ2s-0007Ad-59 for emacs-orgmode@gnu.org; Wed, 22 Dec 2010 15:52:02 +0100 Received: from 94.197.185.4.threembb.co.uk ([94.197.185.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Dec 2010 15:52:02 +0100 Received: from dandavison7 by 94.197.185.4.threembb.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Dec 2010 15:52:02 +0100 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org There's recently been some advocacy of using buffer-local variables for Org-mode configuration. It seems like a good idea to me. However, I think that it raises a problem: there are at least two situations in which Org internally spawns a buffer that is supposed to be a sort of "copy" of another Org buffer: these situations are export and org-src edit buffer. The problem is that the "copy" buffer doesn't inherit local variables from the parent buffer. It seems that either we should propagate all local variables in these cases (but I suspect that is inappropriate for some variables), or we have to have a rule for identifying the subset of local variables which need to be propagated. Below is one example which I think demonstrates a problem. If you evaluate the elisp block and then export to HTML, the noweb does not get expanded, because the configuration variable is buffer-local (behind the scenes, Org creates a buffer copy just before exporting a buffer). --8<---------------cut here---------------start------------->8--- #+title: Local variables issues? Evaluate this block, then do C-c C-e h #+begin_src emacs-lisp :results silent :exports none (set-default 'org-babel-default-header-args:sh nil) (set (make-local-variable 'org-babel-default-header-args:sh) '((:noweb . "yes"))) #+end_src #+begin_src sh :exports both <> #+end_src #+source: foo #+begin_src sh :exports none echo hello #+end_src --8<---------------cut here---------------end--------------->8--- It's also a problem when spawning the org-src edit buffer. There is a patch in the pipeline that tries to identify all the necessary local variables and transmit them to the edit buffer: http://patchwork.newartisans.com/patch/438/ That's a bit messy, but in the export case it seems even harder to identify all variables that might need to be transmitted. What is a good solution? Dan