From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Davison Subject: Re: Problems with buffer-local variables Date: Mon, 31 Jan 2011 20:00:44 +0000 Message-ID: References: <2C2F194F-E800-4A4C-ADF6-4C2F2CFDD6C5@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from [140.186.70.92] (port=36056 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pjzvp-0000Bw-PS for emacs-orgmode@gnu.org; Mon, 31 Jan 2011 15:01:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pjzvl-00024L-NU for emacs-orgmode@gnu.org; Mon, 31 Jan 2011 15:01:01 -0500 Received: from mail-wy0-f169.google.com ([74.125.82.169]:51050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pjzvl-00023g-Fu for emacs-orgmode@gnu.org; Mon, 31 Jan 2011 15:00:57 -0500 Received: by wyj26 with SMTP id 26so6305602wyj.0 for ; Mon, 31 Jan 2011 12:00:56 -0800 (PST) In-Reply-To: <2C2F194F-E800-4A4C-ADF6-4C2F2CFDD6C5@gmail.com> (Carsten Dominik's message of "Fri, 14 Jan 2011 13:22:39 +0100") 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: Carsten Dominik Cc: emacs-orgmode@gnu.org Carsten Dominik 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 >> <> >> #+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