emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lin


From: Darlan Cavalcante Moreira
Subject: Re: [O] [ANN] BREAKING CHANGE -- removing #+BABEL file-wide property lines
Date: Fri, 21 Oct 2011 18:05:26 -0300
User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.0 Mule/6.0 (HANACHIRUSATO)


It's excellent that now babel understands multiple values in the "var"
property (I was one of the people that wanted this), but "There Is One More
Thing".

Would it be feasible to inherit variables from parent sub-trees?
Effectively, I'd like to append new values in lower level sub-trees, but
AFAIK setting the var property in a sub-tree will still replace the value
set in the parent sub-tree.

That is, in the example below the level-2 sub-trees would not have the foo
variable passed to babel.
--8<---------------cut here---------------start------------->8---
* Code with foo
  :PROPERTIES:
  :var:      foo=1
  :END:

** Code only with bar
   :PROPERTIES:
   :var:      bar=2
   :END:
   src_block
** Code only with baz
   :PROPERTIES:
   :var:      baz=3
   :END:
   src_block
--8<---------------cut here---------------end--------------->8---

Maybe a special keyword, such as "inherit" (or "append") could be used to
incorporate variables defined in the parent sub-tree, such that the example
would become
--8<---------------cut here---------------start------------->8---
* Code with foo
  :PROPERTIES:
  :var:      foo=1
  :END:

** Code with foo and bar
   :PROPERTIES:
   :var:      bar=2, inherit
   :END:
   src_block
** Code with foo and baz
   :PROPERTIES:
   :var:      baz=3, inherit
   :END:
   src_block
--8<---------------cut here---------------end--------------->8---

This should not affect global variables and "inherit" would inherit
variables defined only in the parent sub-tree (unless it also contains the
inherit keyword).

As a use case scenario, suppose I need to perform simulations for a few
different scenarios, each with small variations. This would allow me to
define common variables for a scenario in a higher level sub-tree and more
specific variables in the lower level sub-trees.

--
Darlan Cavalcante


At Fri, 21 Oct 2011 22:24:25 +0200,
Christian Moe <address@hidden> wrote:
> 
> Hi,
> 
> Yes, that works nicely, and should solve Rainer's problem.
> I haven't been able to think of anything else that can't be handled by 
> properties.
> 
> And I do think it's a good idea to winnow down the syntax a bit, even 
> if things break. I just like to grumble.
> :-)
> 
> Yours,
> Christian
> 
> On 10/21/11 7:37 PM, Eric Schulte wrote:
> > Nice idea.  This same issue with "var" arose when we first started
> > allowing header arguments to be specified inside subtree properties.
> > I've just implemented your suggestion so the following are now possible.
> >
> > #+PROPERTY: var foo=1, bar=2
> > #+PROPERTY: cache yes
> >
> > #+begin_src emacs-lisp
> >    (+ foo bar)
> > #+end_src
> >
> > #+results[be32e67491d4e92f75769aebe423c20ca01626fe]:
> > : 3
> >
> > and
> >
> > #+begin_src emacs-lisp :var foo="this", bar="that"
> >    (concat foo " " bar)
> > #+end_src
> >
> > #+results[3cde077efa81f1ca24a62ac264dbd5776b6e0054]:
> > : this that
> >
> > Thanks for the suggestion and I hope the above is a sufficient
> > replacement for the now-missing #+BABEL: syntax.
> >
> > Cheers -- Eric
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]