Re: [O] About the use of PROPERTY "meta lines"...
cbe...@tajo.ucsd.edu writes: > 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. > This makes sense > > 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? > No, the above behavior is not expected. I've just pushed up a patch which results in the following behavior, in which the last specification of a property overwrites any previous specifications. #+property: something foo=1 #+property: something+ bar=2 #+property: something foo=10 #+begin_src emacs-lisp org-file-properties #+end_src #+results: | (something . foo=10) | Best, > > (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." > > -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About the use of PROPERTY "meta lines"...
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/
Re: [O] About the use of PROPERTY "meta lines"...
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."
Re: [O] About the use of PROPERTY "meta lines"...
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."
Re: [O] About the use of PROPERTY "meta lines"...
"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/
Re: [O] About the use of PROPERTY "meta lines"...
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
Re: [O] About the use of PROPERTY "meta lines"...
"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. Best -- Eric > > 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." > > Best regards, > Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] About the use of PROPERTY "meta lines"...
#+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. 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." Best regards, Seb -- Sebastien Vauban
