* Problems with buffer-local variables
@ 2010-12-22 14:51 Dan Davison
2011-01-14 12:22 ` Carsten Dominik
0 siblings, 1 reply; 5+ messages in thread
From: Dan Davison @ 2010-12-22 14:51 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Problems with buffer-local variables 2010-12-22 14:51 Problems with buffer-local variables Dan Davison @ 2011-01-14 12:22 ` Carsten Dominik 2011-01-31 20:00 ` Dan Davison 0 siblings, 1 reply; 5+ messages in thread From: Carsten Dominik @ 2011-01-14 12:22 UTC (permalink / raw) To: Dan Davison; +Cc: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with buffer-local variables 2011-01-14 12:22 ` Carsten Dominik @ 2011-01-31 20:00 ` Dan Davison 2011-02-15 17:04 ` [Accepted] " Bastien Guerry 2011-02-15 17:05 ` Bastien 0 siblings, 2 replies; 5+ messages in thread From: Dan Davison @ 2011-01-31 20:00 UTC (permalink / raw) To: Carsten Dominik; +Cc: emacs-orgmode 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 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [Accepted] Problems with buffer-local variables 2011-01-31 20:00 ` Dan Davison @ 2011-02-15 17:04 ` Bastien Guerry 2011-02-15 17:05 ` Bastien 1 sibling, 0 replies; 5+ messages in thread From: Bastien Guerry @ 2011-02-15 17:04 UTC (permalink / raw) To: emacs-orgmode 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. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Problems with buffer-local variables 2011-01-31 20:00 ` Dan Davison 2011-02-15 17:04 ` [Accepted] " Bastien Guerry @ 2011-02-15 17:05 ` Bastien 1 sibling, 0 replies; 5+ messages in thread From: Bastien @ 2011-02-15 17:05 UTC (permalink / raw) To: Dan Davison; +Cc: emacs-orgmode, Carsten Dominik 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-02-16 17:28 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-12-22 14:51 Problems with buffer-local variables Dan Davison 2011-01-14 12:22 ` Carsten Dominik 2011-01-31 20:00 ` Dan Davison 2011-02-15 17:04 ` [Accepted] " Bastien Guerry 2011-02-15 17:05 ` Bastien
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).