emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] About the use of PROPERTY "meta lines"...


From: Torsten Wagner
Subject: Re: [O] About the use of PROPERTY "meta lines"...
Date: Fri, 06 Jan 2012 16:57:12 +0900
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111108 Thunderbird/8.0

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"<address@hidden>  writes:

Hi Eric and all,

Eric Schulte wrote:
"Sebastien Vauban"<address@hidden>  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."





reply via email to

[Prev in Thread] Current Thread [Next in Thread]