From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: About the use of PROPERTY "meta lines"... Date: Fri, 06 Jan 2012 11:07:16 -0700 Message-ID: <87zke0y9kj.fsf@gmx.com> References: <807h1fycsm.fsf@somewhere.org> <871uridlb1.fsf@gmx.com> <80mxa56xmc.fsf@somewhere.org> <87lipl1e0u.fsf@gmx.com> <4F06A958.2080508@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:57755) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjERn-0005lx-VG for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 13:23:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjERm-0007FL-5c for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 13:23:23 -0500 Received: from mailout-us.gmx.com ([74.208.5.67]:54415) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RjERl-0007FF-Oy for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 13:23:22 -0500 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@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Torsten Wagner Cc: Sebastien Vauban , emacs-orgmode@gnu.org Torsten Wagner 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" writes: >> >>> 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 >>> >> >> 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/