From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: About the use of PROPERTY "meta lines"... Date: Fri, 06 Jan 2012 16:57:12 +0900 Message-ID: <4F06A958.2080508@gmail.com> References: <807h1fycsm.fsf@somewhere.org> <871uridlb1.fsf@gmx.com> <80mxa56xmc.fsf@somewhere.org> <87lipl1e0u.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([140.186.70.92]:53564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj4fv-0002PA-3G for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 02:57:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rj4ft-0004VM-UL for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 02:57:19 -0500 Received: from mail-tul01m020-f169.google.com ([209.85.214.169]:52252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rj4ft-0004VC-Pd for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 02:57:17 -0500 Received: by obcwo8 with SMTP id wo8so1852543obc.0 for ; Thu, 05 Jan 2012 23:57:16 -0800 (PST) In-Reply-To: <87lipl1e0u.fsf@gmx.com> 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: Eric Schulte Cc: Sebastien Vauban , emacs-orgmode@gnu.org 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 in contrast, a property-block is only valid of the given tree (and subtrees?). 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. 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." >