Problems with buffer-local variables

Problems with buffer-local variables

[Dan Davison]

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

Re: Problems with buffer-local variables

[Carsten Dominik]

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'.

- Carsten

Re: Problems with buffer-local variables

[Dan Davison]

Carsten Dominik <carsten.dominik@gmail.com> 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
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.
#+end_src

>
> - Carsten

[Accepted] 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 <dandavison7@gmail.com>
> X-Patchwork-Id: 567
> Message-Id: <m1r5bsx2qb.fsf@94.196.190.115.threembb.co.uk>
> To: Carsten Dominik <carsten.dominik@gmail.com>
> Cc: emacs-orgmode@gnu.org
> 
> Carsten Dominik <carsten.dominik@gmail.com> 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.
> 

Re: Problems with buffer-local variables

[Bastien]

Hi Dan,

Dan Davison <dandavison7@gmail.com> writes:

> 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.

I've just tested and applied this - uesful, thanks!

-- 
 Bastien