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

[Darlan Cavalcante Moreira <darcamo@gmail.com>]

I didn't check the list for 3 days and this thread became a little hard to
follow. So, forgive me if I'm "answering" the wrong E-Mail.


I liked Christian's idea of using a single "var" property to tell babel
which regular properties it should use as variables (ignoring any variable
not defined). This would be enough for my use cases.

On the other hand, some way to append values to a property, such as using
some special keyword as I have suggested, could be a better solution in
order to keep consistence if people want this feature for non-babel related
properties.

--
Darlan

At Sat, 22 Oct 2011 09:53:25 -0600,
Eric Schulte wrote:
> 
> Darlan Cavalcante Moreira <darcamo@gmail.com> writes:
> 
> > 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.
> >
> 
> Currently every new property specification entirely replaced previous
> specifications with the same name.
> 
> >
> > That is, in the example below the level-2 sub-trees would not have the foo
> > variable passed to babel.
> > * 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
> >
> > 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
> > * 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
> >
> > 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.
> >
> 
> This sounds somewhat similar to my suggestion in reply to Rainer's
> email.
> 
> Best -- Eric
> 
> >
> > --
> > Darlan Cavalcante
> >
> >
> > At Fri, 21 Oct 2011 22:24:25 +0200,
> > Christian Moe <mail@christianmoe.com> 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
> >> 
> >> 
> 
> -- 
> Eric Schulte
> http://cs.unm.edu/~eschulte/