From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Sebastien Vauban" Subject: Re: About the use of PROPERTY "meta lines"... Date: Tue, 03 Jan 2012 08:42:03 +0100 Message-ID: <80mxa56xmc.fsf@somewhere.org> References: <807h1fycsm.fsf@somewhere.org> <871uridlb1.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org-mXXj517/zsQ@public.gmane.org To: emacs-orgmode-mXXj517/zsQ@public.gmane.org Hi Eric and all, Eric Schulte wrote: > "Sebastien Vauban" 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