Problems with buffer-local variables

[Dan Davison <dandavison7@gmail.com>]

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
<<foo>>
#+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