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 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." -- Sebastien Vauban
