* About the use of PROPERTY "meta lines"... @ 2011-12-29 8:58 Sebastien Vauban 2012-01-02 17:39 ` Eric Schulte 0 siblings, 1 reply; 8+ messages in thread From: Sebastien Vauban @ 2011-12-29 8:58 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ #+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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2011-12-29 8:58 About the use of PROPERTY "meta lines" Sebastien Vauban @ 2012-01-02 17:39 ` Eric Schulte 2012-01-03 7:42 ` Sebastien Vauban 0 siblings, 1 reply; 8+ messages in thread From: Eric Schulte @ 2012-01-02 17:39 UTC (permalink / raw) To: Sebastien Vauban; +Cc: emacs-orgmode "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-02 17:39 ` Eric Schulte @ 2012-01-03 7:42 ` Sebastien Vauban 2012-01-06 7:28 ` Eric Schulte 0 siblings, 1 reply; 8+ messages in thread From: Sebastien Vauban @ 2012-01-03 7:42 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Hi Eric and all, Eric Schulte wrote: > "Sebastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-03 7:42 ` Sebastien Vauban @ 2012-01-06 7:28 ` Eric Schulte 2012-01-06 7:57 ` Torsten Wagner 0 siblings, 1 reply; 8+ messages in thread From: Eric Schulte @ 2012-01-06 7:28 UTC (permalink / raw) To: Sebastien Vauban; +Cc: emacs-orgmode "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> writes: > Hi Eric and all, > > Eric Schulte wrote: >> "Sebastien Vauban" <wxhgmqzgwmuf@spammotel.com> 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-06 7:28 ` Eric Schulte @ 2012-01-06 7:57 ` Torsten Wagner 2012-01-06 17:13 ` cberry 2012-01-06 18:07 ` Eric Schulte 0 siblings, 2 replies; 8+ messages in thread From: Torsten Wagner @ 2012-01-06 7:57 UTC (permalink / raw) To: Eric Schulte; +Cc: Sebastien Vauban, emacs-orgmode 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"<wxhgmqzgwmuf@spammotel.com> writes: > >> Hi Eric and all, >> >> Eric Schulte wrote: >>> "Sebastien Vauban"<wxhgmqzgwmuf@spammotel.com> 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." > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-06 7:57 ` Torsten Wagner @ 2012-01-06 17:13 ` cberry 2012-01-06 18:22 ` Eric Schulte 2012-01-06 18:07 ` Eric Schulte 1 sibling, 1 reply; 8+ messages in thread From: cberry @ 2012-01-06 17:13 UTC (permalink / raw) To: emacs-orgmode Torsten Wagner <torsten.wagner@gmail.com> 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"<wxhgmqzgwmuf@spammotel.com> writes: >> >>> Hi Eric and all, >>> >>> Eric Schulte wrote: >>>> "Sebastien Vauban"<wxhgmqzgwmuf@spammotel.com> 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." ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-06 17:13 ` cberry @ 2012-01-06 18:22 ` Eric Schulte 0 siblings, 0 replies; 8+ messages in thread From: Eric Schulte @ 2012-01-06 18:22 UTC (permalink / raw) To: cberry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1649 bytes --] cberry@tajo.ucsd.edu writes: > Torsten Wagner <torsten.wagner@gmail.com> 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. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: overwriting-properties.org --] [-- Type: text/x-org, Size: 181 bytes --] #+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) | [-- Attachment #3: Type: text/plain, Size: 3133 bytes --] 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"<wxhgmqzgwmuf@spammotel.com> writes: >>> >>>> Hi Eric and all, >>>> >>>> Eric Schulte wrote: >>>>> "Sebastien Vauban"<wxhgmqzgwmuf@spammotel.com> 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: About the use of PROPERTY "meta lines"... 2012-01-06 7:57 ` Torsten Wagner 2012-01-06 17:13 ` cberry @ 2012-01-06 18:07 ` Eric Schulte 1 sibling, 0 replies; 8+ messages in thread From: Eric Schulte @ 2012-01-06 18:07 UTC (permalink / raw) To: Torsten Wagner; +Cc: Sebastien Vauban, emacs-orgmode Torsten Wagner <torsten.wagner@gmail.com> 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"<wxhgmqzgwmuf@spammotel.com> writes: >> >>> Hi Eric and all, >>> >>> Eric Schulte wrote: >>>> "Sebastien Vauban"<wxhgmqzgwmuf@spammotel.com> 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/ ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-01-06 18:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-12-29 8:58 About the use of PROPERTY "meta lines" Sebastien Vauban 2012-01-02 17:39 ` Eric Schulte 2012-01-03 7:42 ` Sebastien Vauban 2012-01-06 7:28 ` Eric Schulte 2012-01-06 7:57 ` Torsten Wagner 2012-01-06 17:13 ` cberry 2012-01-06 18:22 ` Eric Schulte 2012-01-06 18:07 ` Eric Schulte
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).