Torsten Wagner <torsten.wag...@gmail.com> writes: > Hmm... > but this point is really interesting at least worse to write down in the > manual. > From my understanding a > #+PROPERTY: var bar=2 > sets bar globally to 2 > somewhere and many lines and headers later > #+PROPERTY: var bar=5 > would change this value to 5 for either the rest of the file or until a > new assignment is given... > in that way a property line would be an tree-independent global variable >
Two points here. 1) currently #+property: lines are global and affect the entire file regardless of where they are located in the file, there is no notion of different values before or after a particular #+property: line. So in the case above I would expect the var property to have the value bar=5 as the later line will most likely overwrite the former line. 2) there is nothing special about the "var" property which could make it behave differently than other properties. > > in contrast, a property-block is only valid of the given tree (and > subtrees?). > true > > This brings up the question if there is a need for > > #+PROPERTY: const bar=2 > > which would behave exactly the same like var but issue an error message > if someone tries to set it again somewhere in the file. > No, currently *all* properties are set in the same way regardless of their name, and I think this is a simplification worth keeping. Best, > > Torsten > > > > On 01/06/2012 04:28 PM, Eric Schulte wrote: >> "Sebastien Vauban"<wxhgmqzgw...@spammotel.com> writes: >> >>> Hi Eric and all, >>> >>> Eric Schulte wrote: >>>> "Sebastien Vauban"<wxhgmqzgw...@spammotel.com> writes: >>>> >>>>> #+TITLE: Properties >>>>> #+AUTHOR: Seb Vauban >>>>> #+PROPERTY: var foo=1 >>>>> #+PROPERTY: var+ bar=2 >>>>> >>>>> * Abstract >>>>> >>>>> IIUC, properties are set in this way: >>>>> >>>>> - on a file basis, before any heading, through the =PROPERTY= keyword, >>>>> - on a subtree basis, through the =PROPERTIES= block. >>>>> >>>>> My comprehension is that the =PROPERTY= keyword may not be used inside >>>>> "trees", >>>>> and should be ignored if that would happen. >>>> >>>> While it is not normal usage, I think that it is legal for #+PROPERTY: >>>> lines (or #+Option: lines etc...) to appear inside of subtrees. >>> >>> I realize this is not especially a Babel question, but more a Org core >>> question... >>> >>> Thanks for your answer -- which generates a new one, though: what is then >>> the >>> expected *semantics* of such a construct? >>> >>> There are at least 3 different views on such a construct: putting a PROPERTY >>> line inside a subtree... >>> >>> - ... resets some values from that point up to the end of the subtree >>> - ... resets some values from that point up to the end of the buffer >>> - ... defines some values which can have already been by the subtree >>> >> >> I agree this is murky and whatever behavior we want should be clearly >> thought out and documented in the manual. I would argue that you missed >> another possible semantics, the simple semantics which are currently >> implemented in which a property line *anywhere* in a buffer sets a >> global property. >> >> Cheers, >> >>> >>> Best regards, >>> Seb >>> >>>>> The following example shows that either: >>>>> >>>>> - I'm wrong to think so, >>>>> - there is a bug. >>>>> >>>>> What is the right assumption here? >>>>> >>>>> * Subtree >>>>> >>>>> Being located in a subtree, the following lines are ill-placed IMHO: >>>>> >>>>> #+PROPERTY: var foo="Hello >>>>> #+PROPERTY: var+ world" >>>>> >>>>> Though, they're well taken into account: >>>>> >>>>> #+begin_src emacs-lisp >>>>> foo >>>>> #+end_src >>>>> >>>>> #+results: >>>>> : Hello world >>>>> >>>>> These lines have even wiped the definition of =bar= (because of the use >>>>> of =var= >>>>> without any =+=): >>>>> >>>>> #+begin_src emacs-lisp >>>>> (+ foo bar) >>>>> #+end_src >>>>> >>>>> returns the error "Symbol's value as variable is void: bar." >> > -- Eric Schulte http://cs.unm.edu/~eschulte/