[Accepted] [Orgmode] Problems with buffer-local variables

[Bastien Guerry]

Patch 567 (http://patchwork.newartisans.com/patch/567/) is now "Accepted".

Maintainer comment: none

This relates to the following submission:

http://mid.gmane.org/%3Cm1r5bsx2qb.fsf%4094.196.190.115.threembb.co.uk%3E

Here is the original message containing the patch:

> Content-Type: text/plain; charset="utf-8"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Subject: [Orgmode] Problems with buffer-local variables
> Date: Tue, 01 Feb 2011 01:00:44 -0000
> From: Dan Davison <address@hidden>
> X-Patchwork-Id: 567
> Message-Id: <address@hidden>
> To: Carsten Dominik <address@hidden>
> Cc: address@hidden
> 
> Carsten Dominik <address@hidden> writes:
> 
> > 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
> >> <<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?
> >
> >
> > 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'.
> 
> Here's a patch. It clones into the pre-export buffer all buffer-local
> variables that match a regexp (currently "^\\(org-\\|orgtbl-\\)"). We
> might want to watch out for unanticipated side effects.
> 
> This should mean that we can use buffer-local variables to set export
> related variables on a per-buffer basis[1].
> 
> On reflection I think that the src edit buffer case should be dealt with
> as it is currently (by ad-hoc transporting of variables in the org-src
> code). I still stand by my pending patch 438, which tidies up the
> local-variables stuff in org-edit-src-code.
> 
> http://patchwork.newartisans.com/patch/438/
> 
> Dan
> 
> Footnotes:
> [1] Also, we can use the 'local argument to add-hook to set the various
> export hooks.
> 
> 
>     Ensure that buffer-local variables have their effects during export.
>     
>     * lisp/org.el (org-clone-local-variables): New function to copy local
>     variables from another buffer.
>     * lisp/org-exp.el (org-export-preprocess-string): Clone local
>     variables from source org buffer into temporary export preprocessing
>     buffer.
> 
> #+begin_src diff
> #+end_src
> 
> >
> > - Carsten
> 
> 
> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index 97f17e5..6b333a7 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -1028,6 +1028,7 @@ on this string to produce the exported version."
>        (inhibit-read-only t)
>        (drawers org-drawers)
>        (outline-regexp "\\*+ ")
> +      (source-buffer (current-buffer))
>        target-alist rtn)
>  
>      (setq org-export-target-aliases nil
> @@ -1051,6 +1052,7 @@ on this string to produce the exported version."
>  
>        (let ((org-inhibit-startup t)) (org-mode))
>        (setq case-fold-search t)
> +      (org-clone-local-variables source-buffer "^\\(org-\\|orgtbl-\\)")
>        (org-install-letbind)
>  
>        ;; Call the hook
> diff --git a/lisp/org.el b/lisp/org.el
> index 808c9ed..dda97d9 100644
> --- a/lisp/org.el
> +++ b/lisp/org.el
> @@ -8127,6 +8127,18 @@ Possible values in the list of contexts are `table', 
> `headline', and `item'."
>                x nil))
>          varlist))))
>  
> +(defun org-clone-local-variables (from-buffer &optional regexp)
> +  "Clone local variables from FROM-BUFFER.
> +Optional argument REGEXP selects variables to clone."
> +  (mapc
> +   (lambda (pair)
> +     (and (symbolp (car pair))
> +       (or (null regexp)
> +           (string-match regexp (symbol-name (car pair))))
> +       (set (make-local-variable (car pair))
> +            (cdr pair))))
> +   (buffer-local-variables from-buffer)))
> +
>  ;;;###autoload
>  (defun org-run-like-in-org-mode (cmd)
>    "Run a command, pretending that the current buffer is in Org-mode.
>