From: Carsten Dominik <carsten.dominik@gmail.com>
To: Dan Davison <dandavison7@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Problems with buffer-local variables
Date: Fri, 14 Jan 2011 13:22:39 +0100 [thread overview]
Message-ID: <2C2F194F-E800-4A4C-ADF6-4C2F2CFDD6C5@gmail.com> (raw)
In-Reply-To: <m1fwtprhby.fsf@94.197.185.4.threembb.co.uk>
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
next prev parent reply other threads:[~2011-01-14 12:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-22 14:51 Problems with buffer-local variables Dan Davison
2011-01-14 12:22 ` Carsten Dominik [this message]
2011-01-31 20:00 ` Dan Davison
2011-02-15 17:04 ` [Accepted] " Bastien Guerry
2011-02-15 17:05 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2C2F194F-E800-4A4C-ADF6-4C2F2CFDD6C5@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=dandavison7@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).