From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Problems with buffer-local variables Date: Fri, 14 Jan 2011 13:22:39 +0100 Message-ID: <2C2F194F-E800-4A4C-ADF6-4C2F2CFDD6C5@gmail.com> References: Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from [140.186.70.92] (port=44248 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pdig2-0007Mb-9F for emacs-orgmode@gnu.org; Fri, 14 Jan 2011 07:22:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pdifz-0001mD-S6 for emacs-orgmode@gnu.org; Fri, 14 Jan 2011 07:22:46 -0500 Received: from mail-ew0-f41.google.com ([209.85.215.41]:41440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pdifz-0001ly-Mr for emacs-orgmode@gnu.org; Fri, 14 Jan 2011 07:22:43 -0500 Received: by ewy27 with SMTP id 27so1304989ewy.0 for ; Fri, 14 Jan 2011 04:22:42 -0800 (PST) In-Reply-To: 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: Dan Davison Cc: emacs-orgmode@gnu.org On Dec 22, 2010, at 3:51 PM, Dan Davison wrote: > 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? Hi Dan, I see only two possibilities. Either use a list of variables that should be transported, or copy all local variables, or all local variables that match a pattern. An example for doing something like this can be found in org-get-local-variables which is, for example, used by `org-run-like-in-org-mode'. - Carsten