From mboxrd@z Thu Jan 1 00:00:00 1970 From: cberry@tajo.ucsd.edu Subject: Re: About the use of PROPERTY "meta lines"... Date: Fri, 06 Jan 2012 09:13:38 -0800 Message-ID: <874nw892kd.fsf@tajo.ucsd.edu> 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; charset=us-ascii Return-path: Received: from eggs.gnu.org ([140.186.70.92]:57071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjDMY-00079u-7f for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 12:13:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RjDMX-0005fQ-0z for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 12:13:54 -0500 Received: from lo.gmane.org ([80.91.229.12]:46814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RjDMW-0005fM-NC for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 12:13:52 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RjDMU-0007lx-MF for emacs-orgmode@gnu.org; Fri, 06 Jan 2012 18:13:50 +0100 Received: from tajo.ucsd.edu ([137.110.122.165]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2012 18:13:50 +0100 Received: from cberry by tajo.ucsd.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Jan 2012 18:13:50 +0100 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: 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... I think the behavior is trickier than that. This file: ,---- | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | #+property: var+ bar=20 | | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src `---- Yields '30' after each block upon C-c C-e A, suggesting it is the last #+property setting the global property. But this one: ,---- | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src `---- Yields '3' after each block. So the global behavior of the second 'var foo' line depends on there baing a subsequent 'var+' line. Is this really the expected behavior? (Org-mode version 7.8.03) Chuck > 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."