About commit named "Allow multi-line properties to be specified in property blocks"

About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Hello,

I just noticed that commit (8354fd9e0f5fff04665b2272fff6376b15ec0225).

Could we talk about it before pushing it, a few days before the release?

I am a bit worried about the new block types being introduced recently.
Some may be justified, I don't know yet, but "#+begin_property"
definitely isn't.

By looking at the Org syntax. what appears clearly is that Org blocks
are used for contents formatting. Center blocks, quote blocks, verse
blocks, special blocks, example blocks, export blocks, even src blocks
(even though these blocks may be used for very different things, they
exist primarily to display source code)... there's no exception.

On the other hand, Org internals are controlled through keywords,
property drawers, and options on blocks.

As "#+begin_property" block isn't about contents. I can't see any reason
for it to exist under this shape. So, again, can we discuss about
another approach that would not break the logic behind Org's syntax?

I don't fully grasp the problem it tries to solve, but what's wrong
with, for example, "#+property: var multiple couples"? What's wrong
with :var_list: x=1,y=3,z=4 in a property drawer? What's wrong
with #+header: :var x=1, y=2, z=3 just above the source block? As your
already know, #+header can span already on multiple lines.

Hoping we can find a more elegant solution,


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> I just noticed that commit (8354fd9e0f5fff04665b2272fff6376b15ec0225).
>
> Could we talk about it before pushing it, a few days before the release?
>
> I am a bit worried about the new block types being introduced recently.
> Some may be justified, I don't know yet, but "#+begin_property"
> definitely isn't.
>
> By looking at the Org syntax. what appears clearly is that Org blocks
> are used for contents formatting. Center blocks, quote blocks, verse
> blocks, special blocks, example blocks, export blocks, even src blocks
> (even though these blocks may be used for very different things, they
> exist primarily to display source code)... there's no exception.
>
> On the other hand, Org internals are controlled through keywords,
> property drawers, and options on blocks.
>
> As "#+begin_property" block isn't about contents. I can't see any reason
> for it to exist under this shape. So, again, can we discuss about
> another approach that would not break the logic behind Org's syntax?
>
> I don't fully grasp the problem it tries to solve, but what's wrong
> with, for example, "#+property: var multiple couples"? What's wrong
> with :var_list: x=1,y=3,z=4 in a property drawer? What's wrong
> with #+header: :var x=1, y=2, z=3 just above the source block? As your
> already know, #+header can span already on multiple lines.
>
> Hoping we can find a more elegant solution,
>

The only problem with a single #+PROPERTY: line is that this line could
become unreadably long.  By allowing such an entry to span multiple
lines it becomes feasible to chain together many variables into a single
property.  Another approach which is easily implementable would be to
use syntax like the following...


  #+PROPERTY:  var foo=1,
  #+PROPERTY+:     bar=2,
  #+PROPERTY+:     baz=3,
  #+PROPERTY+:     qux=4

  #+begin_src emacs-lisp
    (+ foo bar baz qux)
  #+end_src

  #+results:
  : 10

Although I originally switched from the above to the implemented because
I thought that using a block would be more consistent with Org-mode
syntax.  Also, the above is undesirable in its requires the PROPERTY+
lines to care about their position in the Org-mode file, which isn't
normally the case.

I think of #+FOO: lines as containers for anything that fits on a single
line, and as blocks as containers for anything that requires a line
break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML.

I didn't realize that there was an extra semantics of blocks as
formatting, and I'm not sure if such an association is desirable or
intentional.

Best -- Eric

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Eric Schulte <schulte.eric@gmail.com> writes:

> The only problem with a single #+PROPERTY: line is that this line could
> become unreadably long.  By allowing such an entry to span multiple
> lines it becomes feasible to chain together many variables into a single
> property.  Another approach which is easily implementable would be to
> use syntax like the following...
>
>
>   #+PROPERTY:  var foo=1,
>   #+PROPERTY+:     bar=2,
>   #+PROPERTY+:     baz=3,
>   #+PROPERTY+:     qux=4

Well, what about:

#+begin_src org
#+property: :var foo=1
#+property: :var bar=2
#+property: :var baz=3
#+property: :var qux=4
#+end_src

Sure, we repeat ":var" more times, but at least, it's consistent with
the rest of Org.

> Although I originally switched from the above to the implemented
> because I thought that using a block would be more consistent with
> Org-mode syntax.

No, as I said, no block has ever controlled Org internals. That's a job
for keywords and property drawers.

> Also, the above is undesirable in its requires the PROPERTY+ lines to
> care about their position in the Org-mode file, which isn't normally
> the case.

Yes, "#+property+:" would be atypical in that situation.

> I think of #+FOO: lines as containers for anything that fits on
> a single line, and as blocks as containers for anything that requires
> a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML.

That comparison with "#+html" and "#+begin_html" doesn't hold as most
"#+keyword:" syntax don't have an equivalent block "#+begin_keyword",
and the other way. Look again at every block type in Org, and see if
there's any equivalent use of the "#+begin_property" you're introducing.
I don't think so.

Moreover, some keywords can be repeated on multiple lines. Think about
"#+text:" before first headline, or "#+header:" before a src block. So,
clearly, "#+keyword:" isn't just about things that must fit on a single
line.

Also, you don't really need a line break here, since you will eventually
parse the values line by line anyway, and not as a block or a paragraph.

You want to add syntactic sugar. There's nothing wrong with it though,
but not everyone appreciate aspartame ;)

> I didn't realize that there was an extra semantics of blocks as
> formatting, and I'm not sure if such an association is desirable or
> intentional.

It is desirable to have a logic behind syntax, and to always refer to
it. Thus, is is desirable to separate syntax used for contents from
syntax used for Org control. It's very different from "things on
a single line vs things on multiple lines".


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> The only problem with a single #+PROPERTY: line is that this line could
>> become unreadably long.  By allowing such an entry to span multiple
>> lines it becomes feasible to chain together many variables into a single
>> property.  Another approach which is easily implementable would be to
>> use syntax like the following...
>>
>>
>>   #+PROPERTY:  var foo=1,
>>   #+PROPERTY+:     bar=2,
>>   #+PROPERTY+:     baz=3,
>>   #+PROPERTY+:     qux=4
>
> Well, what about:
>
> #+property: :var foo=1
> #+property: :var bar=2
> #+property: :var baz=3
> #+property: :var qux=4
>
> Sure, we repeat ":var" more times, but at least, it's consistent with
> the rest of Org.
>

Unfortunately this won't work, the final value of the "var" property
will be "qux=4" rather than "foo=1, bar=2, baz=3, qux=4".

>
>> Although I originally switched from the above to the implemented
>> because I thought that using a block would be more consistent with
>> Org-mode syntax.
>
> No, as I said, no block has ever controlled Org internals. That's a job
> for keywords and property drawers.
>

I would say that the block is defining an keyword, but yes, I suppose
we've never had a multi-line keyword definition structure.

>
>> Also, the above is undesirable in its requires the PROPERTY+ lines to
>> care about their position in the Org-mode file, which isn't normally
>> the case.
>
> Yes, "#+property+:" would be atypical in that situation.
>
>> I think of #+FOO: lines as containers for anything that fits on
>> a single line, and as blocks as containers for anything that requires
>> a line break, e.g., #+HTML and #+BEGIN_HTML/#+END_HTML.
>
> That comparison with "#+html" and "#+begin_html" doesn't hold as most
> "#+keyword:" syntax don't have an equivalent block "#+begin_keyword",

Along these lines I would also like to allow TBLFM lines to be broken
over multiple lines, as I often find myself right-scrolling in a buffer
to find equations in large spreadsheets.  I wonder if there would be a
general solution to allow *all* #keyword+ lines to have a block
equivalent.

> 
> and the other way. Look again at every block type in Org, and see if
> there's any equivalent use of the "#+begin_property" you're
> introducing.  I don't think so.
>

agreed

>
> Moreover, some keywords can be repeated on multiple lines. Think about
> "#+text:" before first headline, or "#+header:" before a src block. So,
> clearly, "#+keyword:" isn't just about things that must fit on a single
> line.
>

I don't know how #+text: works, but with #+header: the order of the
blocks is not important, i.e.,

#+headers: :var a=1
#+headers: :cache a=2

is equal to

#+headers: :cache a=2
#+headers: :var a=1

but the same is not true for

#+PROPERTY:  var foo=1,
#+PROPERTY+:     bar=2

and

#+PROPERTY+:     bar=2
#+PROPERTY:  var foo=1,

>
> Also, you don't really need a line break here, since you will eventually
> parse the values line by line anyway, and not as a block or a paragraph.
>
> You want to add syntactic sugar. There's nothing wrong with it though,
> but not everyone appreciate aspartame ;)
>

Yes, if you dig way back into this thread you'll see the motivation,
basically there are times when a user will want to specify *many*
variables in a single property specification.  If there is a more
natural syntax I am very open to suggestions.

>
>> I didn't realize that there was an extra semantics of blocks as
>> formatting, and I'm not sure if such an association is desirable or
>> intentional.
>
> It is desirable to have a logic behind syntax, and to always refer to
> it. Thus, is is desirable to separate syntax used for contents from
> syntax used for Org control. It's very different from "things on
> a single line vs things on multiple lines".
>

Sure, but to play devils (or my own) advocate, I would say that
simplicity is important and "blocks for multi-line content" is a simpler
rule than "blocks for formatting of multi-line content, and for naming
multi-line data", the second being the case with code and example
blocks.

My goal here is to find the most natural solution which conforms to
Org-modes design as well as possible, I just don't know what that would
be...

Cheers -- Eric

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Hello,

Eric Schulte <schulte.eric@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Well, what about:
>>
>> #+property: :var foo=1
>> #+property: :var bar=2
>> #+property: :var baz=3
>> #+property: :var qux=4

> Unfortunately this won't work, the final value of the "var" property
> will be "qux=4" rather than "foo=1, bar=2, baz=3, qux=4".

I know that it won't work, as "#+begin_property" didn't work before you
introduced it. The idea is to make that work instead (with or without
the colons in front of "var").

> I would say that the block is defining an keyword, but yes, I suppose
> we've never had a multi-line keyword definition structure.

I differentiate keywords and blocks from their usage. As such, blocks
are not defining a keyword. They're not even in the same league.

> Along these lines I would also like to allow TBLFM lines to be broken
> over multiple lines, as I often find myself right-scrolling in a buffer
> to find equations in large spreadsheets.  I wonder if there would be a
> general solution to allow *all* #keyword+ lines to have a block
> equivalent.

The solution I implemented in my document on Org syntax is to create two
keyword's families: cumulative and dual.

Belonging to the first one means a keyword accumulates its values on
multiple calls instead of replacing them. That's how I parse
"#+headers:" or "#+attr_latex" lines, for example. The second one allows
the keyword to have a secondary, optional, value, in square brackets.
This is useful for keywords like "#+results:", which can include an hash
value like "#+results[hash-string]: keyword-value".

Typically, what is required here is to add "#+property:" to the
cumulative family. Thus,

#+property: var foo=1
#+property: var bar=2

is exactly the same as #+property: var foo=1 var bar=2.

Also, make sure var assignations accumulate too.

> I don't know how #+text: works, but with #+header: the order of the
> blocks is not important, i.e.,
>
> #+headers: :var a=1
> #+headers: :cache a=2
>
> is equal to
>
> #+headers: :cache a=2
> #+headers: :var a=1
>
> but the same is not true for
>
> #+PROPERTY:  var foo=1,
> #+PROPERTY+:     bar=2
>
> and
>
> #+PROPERTY+: bar=2
> #+PROPERTY:  var foo=1,

Because, again, "#+property+:" isn't a great idea. Here, "#+headers:"
accumulates its values. Make the same for "#+property:" and we're all
set.

>> It is desirable to have a logic behind syntax, and to always refer to
>> it. Thus, is is desirable to separate syntax used for contents from
>> syntax used for Org control. It's very different from "things on
>> a single line vs things on multiple lines".

> Sure, but to play devils (or my own) advocate, I would say that
> simplicity is important and "blocks for multi-line content" is a simpler
> rule than "blocks for formatting of multi-line content, and for naming
> multi-line data", the second being the case with code and example
> blocks.

What? Blocks do not name anything. In the case of code and example
blocks, you specify Org how to format/understand the contents, like any
other block. You use "#+name:" to name them.

Again, the rule is simple: blocks are directly related to contents,
keywords aren't. Corollary is: no block with only options and no
contents.

> My goal here is to find the most natural solution which conforms to
> Org-modes design as well as possible, I just don't know what that
> would be...

We share the same goal.


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Correcting myself,

> Typically, what is required here is to add "#+property:" to the
> cumulative family. Thus,
>
> #+property: var foo=1
> #+property: var bar=2
>
> is exactly the same as #+property: var foo=1 var bar=2.
>
> Also, make sure var assignations accumulate too.

I don't think "#+property:" should belong to a cumulative family of
keywords. But Babel "var" keyword definitely should. Thus, the idea
stays the same: on multiple "var" calls, accumulate values instead of
replacing them (unless, obviously, the variables has already been
assigned a value before).

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Correcting myself,
>
>> Typically, what is required here is to add "#+property:" to the
>> cumulative family. Thus,
>>
>> #+property: var foo=1
>> #+property: var bar=2
>>
>> is exactly the same as #+property: var foo=1 var bar=2.
>>
>> Also, make sure var assignations accumulate too.
>
> I don't think "#+property:" should belong to a cumulative family of
> keywords. But Babel "var" keyword definitely should. Thus, the idea
> stays the same: on multiple "var" calls, accumulate values instead of
> replacing them (unless, obviously, the variables has already been
> assigned a value before).

This was one of the proposed options to solve this problem, namely
introduce a list of properties whose value accumulates rather than is
replaced.  Since the property list data structure only allows each key
to appear once, the accumulation would necessarily occur on the value
side, so assuming "var" is an accumulating property, then 

#+property: var foo=1
#+property: var bar=2

would result in `org-file-properties' having the following value

  (("var" . "foo=1 bar=1"))

Which with some changes in the code-block side code could be used by
code blocks to assign multiple variables.

I went with changing property syntax rather than internal behavior
because I am not overly familiar with properties or the code with which
they were implemented and I felt (probably incorrectly) that this would
be a less dramatic change to Org-mode.  I'm happy to work up a solution
along the lines suggested above, which would introduce a variable like
`org-accumulating-properties' or some-such which would default to only
holding the "var" property name

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Eric Schulte <schulte.eric@gmail.com> writes:

> This was one of the proposed options to solve this problem, namely
> introduce a list of properties whose value accumulates rather than is
> replaced.  Since the property list data structure only allows each key
> to appear once, the accumulation would necessarily occur on the value
> side, so assuming "var" is an accumulating property, then 
>
> #+property: var foo=1
> #+property: var bar=2
>
> would result in `org-file-properties' having the following value
>
>   (("var" . "foo=1 bar=1"))
>
> Which with some changes in the code-block side code could be used by
> code blocks to assign multiple variables.
>
> I went with changing property syntax rather than internal behavior
> because I am not overly familiar with properties or the code with which
> they were implemented and I felt (probably incorrectly) that this would
> be a less dramatic change to Org-mode.  I'm happy to work up a solution
> along the lines suggested above, which would introduce a variable like
> `org-accumulating-properties' or some-such which would default to only
> holding the "var" property name

That sounds way better to me. It's just a matter of modifying the
following part in `org-set-regexps-and-options'.

#+begin_src emacs-lisp
((equal key "PROPERTY")
 (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
   (push (cons (match-string 1 value) (match-string 2 value))
         props)))
#+end_src

If we want to be a bit more future-proof on that side, we may even
refine the `org-accumulating-properties' idea by making it an
`org-accumulated-properties-alist' where key is property's name and
value a symbol describing how they are accumulated. That symbol could
be, for example `space', `comma', `newline', `consed'.


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> This was one of the proposed options to solve this problem, namely
>> introduce a list of properties whose value accumulates rather than is
>> replaced.  Since the property list data structure only allows each key
>> to appear once, the accumulation would necessarily occur on the value
>> side, so assuming "var" is an accumulating property, then 
>>
>> #+property: var foo=1
>> #+property: var bar=2
>>
>> would result in `org-file-properties' having the following value
>>
>>   (("var" . "foo=1 bar=1"))
>>
>> Which with some changes in the code-block side code could be used by
>> code blocks to assign multiple variables.
>>
>> I went with changing property syntax rather than internal behavior
>> because I am not overly familiar with properties or the code with which
>> they were implemented and I felt (probably incorrectly) that this would
>> be a less dramatic change to Org-mode.  I'm happy to work up a solution
>> along the lines suggested above, which would introduce a variable like
>> `org-accumulating-properties' or some-such which would default to only
>> holding the "var" property name
>
> That sounds way better to me. It's just a matter of modifying the
> following part in `org-set-regexps-and-options'.
>
> #+begin_src emacs-lisp
> ((equal key "PROPERTY")
>  (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
>    (push (cons (match-string 1 value) (match-string 2 value))
>          props)))
> #+end_src
>
> If we want to be a bit more future-proof on that side, we may even
> refine the `org-accumulating-properties' idea by making it an
> `org-accumulated-properties-alist' where key is property's name and
> value a symbol describing how they are accumulated. That symbol could
> be, for example `space', `comma', `newline', `consed'.
>

Beautiful,

The attached patch implements this idea with an alist as you specify
above.  If we can reach some sort of agreement that this is the best way
forward I will revert the property blocks and add this patch.

Unfortunately I don't know what constitutes agreement, or who the vested
interest holders are in this sort of decision.  I would be nice if
Carsten or Bastien could weigh in.

Cheers -- Eric

As an aside discussions like this are part of why I really enjoy working
on Org-mode.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-some-properties-to-accumulate-see-org-accumula.patch --]
[-- Type: text/x-diff, Size: 2672 bytes --]

From 2496eec5ad79c7e4e4f3804efb1bbce17f913704 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Tue, 1 Nov 2011 10:56:36 -0600
Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist').

  The default value of this new variable is '(("var" . ", "))
  resulting in the following behavior

  #+property: var foo=1
  #+property: var bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

* lisp/org.el (org-accumulated-properties-alist): Adding an alist
  which specifies which properties may be accumulated and how.
  (org-set-regexps-and-options): Make use of accumulating properties
  when collecting said.
---
 lisp/org.el |   28 ++++++++++++++++++++++++++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 318ccfd..b34d274 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.")
 
+(defcustom org-accumulated-properties-alist
+  '(("var" . ", "))
+  "Alist of properties whose values should accumulate rather than overwrite.
+Each element of this alist should include both a string property
+name as well as the string connector used to join multiple values
+for this property.  So for example using the default value of
+this list which associates \"var\" with \", \", the following
+Org-mode text,
+
+  #+PROPERTY: var foo=1
+  #+PROPERTY: var bar=2
+
+will result in the following being added to `org-file-properties'.
+
+  '(\"var\" . \"foo=1, bar=2\")")
+
 (defun org-set-regexps-and-options ()
   "Precompute regular expressions for current buffer."
   (when (eq major-mode 'org-mode)
@@ -4492,8 +4508,16 @@ means to push this value onto the list in the variable.")
 	      (setq prio (org-split-string value " +")))
 	     ((equal key "PROPERTY")
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props)))
+		(let* ((prop (match-string 1 value))
+		       (value (match-string 2 value))
+		       (str (cdr (assoc prop org-accumulated-properties-alist)))
+		       (existing (cdr (assoc prop props))))
+		  (if (and str existing)
+		      (setq props (cons (cons prop (concat existing str value))
+					(org-remove-if (lambda (p)
+							 (string= (car p) prop))
+						       props)))
+		    (push (cons prop value) props)))))
 	     ((equal key "FILETAGS")
 	      (when (string-match "\\S-" value)
 		(setq ftags
-- 
1.7.4.1


[-- Attachment #3: Type: text/plain, Size: 63 bytes --]


>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 11/1/11 5:58 PM, Eric Schulte wrote:

>>>  so assuming "var" is an accumulating property, then
>>>
>>> #+property: var foo=1
>>> #+property: var bar=2
>>>
>>> would result in `org-file-properties' having the following value
>>>
>>>    (("var" . "foo=1 bar=1"))

Given this:

---


#+property: var foo=1
#+property: var bar=2

* Heading
   :PROPERTIES:
   :var: foo=3
   :END:


---

Would it result in (("var" . "foo=3 bar=2"))?

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

Christian Moe <mail@christianmoe.com> writes:

> On 11/1/11 5:58 PM, Eric Schulte wrote:
>
>>>>  so assuming "var" is an accumulating property, then
>>>>
>>>> #+property: var foo=1
>>>> #+property: var bar=2
>>>>
>>>> would result in `org-file-properties' having the following value
>>>>
>>>>    (("var" . "foo=1 bar=1"))
>
> Given this:
>
> ---
>
>
> #+property: var foo=1
> #+property: var bar=2
>
> * Heading
>    :PROPERTIES:
>    :var: foo=3
>    :END:
>
>
> ---
>
> Would it result in (("var" . "foo=3 bar=2"))?
>

Good catch Christian, I get the following behavior, currently seems the
property-block specification overwrites the global property.  I'll have
to update my patch to append at the subheading level as well.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: something.org --]
[-- Type: text/x-org, Size: 400 bytes --]

#+property: var foo=1
#+property: var bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1, bar=2

* heading
  :PROPERTIES:
  :var:      foo=4
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 4

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=4

[-- Attachment #3: Type: text/plain, Size: 347 bytes --]


As for variable handling, I think the solution is to ensure that on the
code-block side of things, a var string like "foo=3, bar=2, foo=1"
results in,

foo=1
bar=2

that is, subtree variable definitions will pre-empty earlier definitions
of the same variable..

Best -- Eric

>
> Yours,
> Christian

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 11/1/11 8:02 PM, Eric Schulte wrote:
> As for variable handling, I think the solution is to ensure that on the
> code-block side of things, a var string like "foo=3, bar=2, foo=1"
> results in,
>
> foo=1
> bar=2
>
> that is, subtree variable definitions will pre-empty earlier definitions
> of the same variable..

Yes, that sounds like the way to go. My previous message implied that 
the var string should only contain unique variable names, but I see 
that that would be needlessly complicated.

This is an interesting approach; I like it better than the property 
block. I'm sure we will think of other useful applications for 
cumulative properties, too (conversely, there'll probably be some side 
effect that will turn around and bite us at some point, though I can't 
think what it would be).

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Christian Moe <mail@christianmoe.com> writes:

> On 11/1/11 8:02 PM, Eric Schulte wrote:
>> As for variable handling, I think the solution is to ensure that on the
>> code-block side of things, a var string like "foo=3, bar=2, foo=1"
>> results in,
>>
>> foo=1
>> bar=2
>>
>> that is, subtree variable definitions will pre-empty earlier definitions
>> of the same variable..
>
> Yes, that sounds like the way to go. My previous message implied that
> the var string should only contain unique variable names, but I see
> that that would be needlessly complicated.
>
> This is an interesting approach; I like it better than the property
> block.

Me too.

> I'm sure we will think of other useful applications for cumulative
> properties, too (conversely, there'll probably be some side effect
> that will turn around and bite us at some point, though I can't think
> what it would be).
>

Hopefully more of the former and less of the later.

Attached is a new patch, which handles subtree inheritance
appropriately, resulting in the following behavior.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: something.org --]
[-- Type: text/x-org, Size: 414 bytes --]

#+property: var foo=1
#+property: var bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1, bar=2

* heading
  :PROPERTIES:
  :var:      foo=7
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 7

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1, bar=2, foo=7

[-- Attachment #3: Type: text/plain, Size: 17 bytes --]


Thanks -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0001-Allow-some-properties-to-accumulate-see-org-accumula.patch --]
[-- Type: text/x-diff, Size: 4760 bytes --]

From ff3330193da27a6b0dcf4be92ed54424040ddaec Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Tue, 1 Nov 2011 10:56:36 -0600
Subject: [PATCH] Allow some properties to accumulate (see `org-accumulated-properties-alist').

  The default value of this new variable is '(("var" . ", "))
  resulting in the following behavior

  #+property: var foo=1
  #+property: var bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2

  * heading
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2, foo=7

* lisp/org.el (org-accumulated-properties-alist): Adding an alist
  which specifies which properties may be accumulated and how.
  (org-set-regexps-and-options): Make use of accumulating properties
  when collecting said.
  (org-property-from-plists): Return the (possibly accumulated) value
  of property from plists.
  (org-entry-get-with-inheritance): Inherit accumulated properties
  appropriately.
---
 lisp/org.el |   52 ++++++++++++++++++++++++++++++++++++++++++++++------
 1 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 318ccfd..2fe8d92 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4431,6 +4431,22 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.")
 
+(defcustom org-accumulated-properties-alist
+  '(("var" . ", "))
+  "Alist of properties whose values should accumulate rather than overwrite.
+Each element of this alist should include both a string property
+name as well as the string connector used to join multiple values
+for this property.  So for example using the default value of
+this list which associates \"var\" with \", \", the following
+Org-mode text,
+
+  #+PROPERTY: var foo=1
+  #+PROPERTY: var bar=2
+
+will result in the following being added to `org-file-properties'.
+
+  '(\"var\" . \"foo=1, bar=2\")")
+
 (defun org-set-regexps-and-options ()
   "Precompute regular expressions for current buffer."
   (when (eq major-mode 'org-mode)
@@ -4492,8 +4508,13 @@ means to push this value onto the list in the variable.")
 	      (setq prio (org-split-string value " +")))
 	     ((equal key "PROPERTY")
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props)))
+		(let* ((prp (match-string 1 value))
+		       (val (match-string 2 value))
+		       (new (org-property-from-plists
+			     prp `((,prp . ,val)) props)))
+		  (setq props (cons (cons prp new)
+				    (org-remove-if (lambda (p) (string= (car p) prp))
+						   props))))))
 	     ((equal key "FILETAGS")
 	      (when (string-match "\\S-" value)
 		(setq ftags
@@ -14170,6 +14191,24 @@ no match, the marker will point nowhere.
 Note that also `org-entry-get' calls this function, if the INHERIT flag
 is set.")
 
+(defun org-property-from-plists (property &rest plists)
+  "Return PROPERTY from PLISTS respecting `org-accumulated-properties-alist'."
+  (flet ((until (fn lst) (when (not (null lst))
+			   (or (funcall fn (car lst))
+			       (funcall fn (cdr lst))))))
+    (let ((str (cdr (assoc property org-accumulated-properties-alist))))
+      (if str
+	  (let (result)
+	    (mapc (lambda (plist)
+		    (let ((value (cdr (assoc property plist))))
+		      (when value
+			(setq result (if result
+					 (concat value str result)
+				       value)))))
+		  plists)
+	    result)
+	(until (lambda (plist) (cdr (assoc property plist))) plists)))))
+
 (defun org-entry-get-with-inheritance (property &optional literal-nil)
   "Get entry property, and search higher levels if not present.
 The search will stop at the first ancestor which has the property defined.
@@ -14189,10 +14228,11 @@ However, if LITERAL-NIL is set, return the string value \"nil\" instead."
 		(move-marker org-entry-property-inherited-from (point))
 		(throw 'ex tmp))
 	      (or (org-up-heading-safe) (throw 'ex nil)))))))
-    (setq tmp (or tmp
-		  (cdr (assoc property org-file-properties))
-		  (cdr (assoc property org-global-properties))
-		  (cdr (assoc property org-global-properties-fixed))))
+    (setq tmp (org-property-from-plists property
+					`((,property . ,tmp))
+					org-file-properties
+					org-global-properties
+					org-global-properties-fixed))
     (if literal-nil tmp (org-not-nil tmp))))
 
 (defvar org-property-changed-functions nil
-- 
1.7.4.1


[-- Attachment #5: Type: text/plain, Size: 71 bytes --]


>
> Yours,
> Christian

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 10/31/11 9:49 PM, Nicolas Goaziou wrote:
> #+begin_src org
> #+property: :var foo=1
> #+property: :var bar=2
> #+property: :var baz=3
> #+property: :var qux=4
> #+end_src

Two problems:

1) You need to drop the colons before var.

2) The outcome is not what you expect.

----

#+property: var foo=1
#+property: var bar=2
#+property: var baz=3
#+property: var qux=4

#+begin_src perl :results output
   print "foo is $foo, bar is $bar, baz is $baz, qux is $qux"
#+end_src

#+results:
: foo is 1, bar is , baz is , qux is

----

Because as things currently work, further assignments to the same 
property (var) by subsequent #+PROPERTY lines are ignored. (Whereas 
further assignments to the same property in property drawers further 
down an outline tree will `overwrite' assignments higher up.)

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

Hi,

Having followed the thread on Babel and properties after the removal 
of the #+BABEL headers, I understand the motivation for introducing this.

But I share Nicolas' feelings that a property block doesn't rhyme with 
existing usage of blocks and properties.

There were many other ideas that came up:

1. PROPERTY+ lines (as discussed in Eric's message above).

2. A similar approach to the table formula editor (C-c ') for properties.

3. Allowing some properties to accumulate values, in particular making 
the :var: property for Babel blocks cumulative (slightly different 
versions suggested by Eric and Darlan; either would require some 
changes to Org's property handling), and

4. My own idea of allowing any defined property to be passed as an 
argument to src blocks (which would require some changes to how Babel 
reads its :var header args).

Solutions 1-2 would solve the long lines problem. Solutions 2-4 would 
avoid introducing new syntax (#+BEGIN_PROPERTY or #+PROPERTY+) largely 
to make up for having removed old syntax (#+BABEL). Solutions 3-4 
would have wide-ranging effects and would need some careful study, but 
I think the advantages might outweigh the risks.

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

>
> 4. My own idea of allowing any defined property to be passed as an
> argument to src blocks (which would require some changes to how Babel
> reads its :var header args).
>

I do see how this approach could be powerful, however I fear both the
size of the change and the potential negative consequences of combining
the property and variable name spaces.

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 10/31/11 10:36 PM, Eric Schulte wrote:
>>
>> 4. My own idea of allowing any defined property to be passed as an
>> argument to src blocks (which would require some changes to how Babel
>> reads its :var header args).
>>
>
> I do see how this approach could be powerful, however I fear both the
> size of the change and the potential negative consequences of combining
> the property and variable name spaces.
>

Well, you would know better than me on both scores, so I'll stop 
pushing. Thanks for considering it.

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Bastien]

Dear all,

here is my take on this issue.

First of all, sorry that the #+begin_property caused confusion, 
I'm the one responsible as I suggested this suggestion to Eric.

I can see three issues:

1) Consistent syntax for #+xxx and #+begin_xxx?

   Nicolas point is valid -- #+begin_xxx syntax is about content and
   formatting, not about Org's internal.  #+xxx is mostly about Org's
   internals (#+author, #+date, #+property, etc) and sometimes about
   content, as a convenient way of inserting one-line content block
   (#+html, #+LaTeX, etc)

   #+begin_property does not fit well into this picture.

2) "Cumulative properties"?

   Org's manual describes #+property like this:
 
   `#+PROPERTY: Property_Name Value'
       This line sets a default inheritance value for entries in the
       current buffer, most useful for specifying the allowed values 
       of a property.

   Note that #+property: var foo=1 does *not* fit into the syntax
   described above.  It is more something like

   `#+PROPERTY: var Variable_Name=Value'

   Hence the problem of accumulating the "values" of "var", which 
   is not really a property name, but some syntactic clue to bind
   Variable_Name to its value.

   Here is a suggestion: use a syntaxe like
 
   #+var: foo 1

   The difference between #+property and #+var would be that #+var 
   is for setting general purpoes (elisp) variables, while #+property
   is for Org internals.  Sorry if such a proposal has already been
   made and discussed.  

   My feeling is that `org-accumulated-properties-alist' is complex
   and can be avoided -- but I need to think more about this.

3) Wrapping/folding long #+xxx lines?

   This is an independant request -- see Robert McIntyre's recent
   question on the list.  The problem is that fill-paragraph on
   long #+xxx lines breaks the line into comment lines, which is 
   wrong.  Filling like this:

   #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
          : @3$2=@1$2+@2$2::...
          : @3$2=@1$2+@2$2::...

   would feel more natural, at least to me.  But maybe generalizing
   the #+begin_xxx syntax for *all* #+xxx keywords.  This would make the
   current org-internals-oriented/content-oriented difference between
   #+xxx and #+begin_xxx obsolete, but this would spare us the cost of
   new syntax.  Curious about input about this as well.

Cheers,

-- 
 Bastien

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

> 1) Consistent syntax for #+xxx and #+begin_xxx?
>
>    Nicolas point is valid -- #+begin_xxx syntax is about content and
>    formatting, not about Org's internal.  #+xxx is mostly about Org's
>    internals (#+author, #+date, #+property, etc) and sometimes about
>    content, as a convenient way of inserting one-line content block
>    (#+html, #+LaTeX, etc)

For the sake of consistency, I would suggest to drop the export back-end
relative keywords. "#+html:" and "#+latex:" are indeed disturbing
exceptions to the rule. They are also not so convenient (a net gain of
2 lines).

>
> 2) "Cumulative properties"?
>
>    Here is a suggestion: use a syntaxe like
>  
>    #+var: foo 1

There is also "#+bind:", whose purpose is close enough.

> 3) Wrapping/folding long #+xxx lines?
>
>    This is an independant request -- see Robert McIntyre's recent
>    question on the list.  The problem is that fill-paragraph on
>    long #+xxx lines breaks the line into comment lines, which is 
>    wrong.  Filling like this:
>
>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>           : @3$2=@1$2+@2$2::...
>           : @3$2=@1$2+@2$2::...

#+tblfm: ...
#+tblfm: ...
#+tblfm: ...

may be more intrusive, but also more consistent with "#+text:" and
"#+headers:" keywords.

>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>    keywords.  This would make the current
>    org-internals-oriented/content-oriented difference between #+xxx
>    and #+begin_xxx obsolete

I suggest to avoid such a thing. Here are a few, more or less valid,
reasons:

  - That distinction is useful for the user (clear separation between
    contents and Org control).
  - It would penalize usage of special blocks.
  - The need is localized to very few keywords: it isn't worth the added
    complexity.
  - It would be ugly: no more nice stacking of keywords, but a mix of
    blocks and keywords, and blocks on top of blocks... Org syntax may
    not be the prettiest ever, it doesn't deserve that.
  - It would be a real pain to parse.

>    but this would spare us the cost of new syntax.

On the contrary, creating a block for each keyword would mean a lot of
new syntax.

We currently have 8 types of blocks (not counting dynamic blocks, whose
syntax is a bit different), all requiring to be parsed differently:

  1. Center blocks,
  2. Comment blocks,
  3. Example blocks,
  4. Export blocks,
  5. Quote blocks,
  6. Special blocks,
  7. Src blocks,
  8. Verse blocks.

While others may sparingly be added in the future, I don't think
introducing scores of them at the same time would help clarifying Org's
syntax.


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Bastien]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> For the sake of consistency, I would suggest to drop the export back-end
> relative keywords. "#+html:" and "#+latex:" are indeed disturbing
> exceptions to the rule. They are also not so convenient (a net gain of
> 2 lines).

Why not.  But let's not break backward compatibility just for the 
sake of consistency.

>> 2) "Cumulative properties"?
>>
>>    Here is a suggestion: use a syntaxe like
>>  
>>    #+var: foo 1
>
> There is also "#+bind:", whose purpose is close enough.

Indeed.  Eric, would it be possible to use 

#+bind foo 1 

instead of 

#+property var foo=1

?

>> 3) Wrapping/folding long #+xxx lines?
>>
>>    This is an independant request -- see Robert McIntyre's recent
>>    question on the list.  The problem is that fill-paragraph on
>>    long #+xxx lines breaks the line into comment lines, which is 
>>    wrong.  Filling like this:
>>
>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>>           : @3$2=@1$2+@2$2::...
>>           : @3$2=@1$2+@2$2::...
>
> #+tblfm: ...
> #+tblfm: ...
> #+tblfm: ...

Not very elegant, but perhaps more efficient/consistent.

>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>>    keywords.  This would make the current
>>    org-internals-oriented/content-oriented difference between #+xxx
>>    and #+begin_xxx obsolete
>
> I suggest to avoid such a thing. Here are a few, more or less valid,
> reasons:
>
>   - That distinction is useful for the user (clear separation between
>     contents and Org control).
>   - It would penalize usage of special blocks.
>   - The need is localized to very few keywords: it isn't worth the added
>     complexity.
>   - It would be ugly: no more nice stacking of keywords, but a mix of
>     blocks and keywords, and blocks on top of blocks... Org syntax may
>     not be the prettiest ever, it doesn't deserve that.
>   - It would be a real pain to parse.

Well, I agree with most of the reasons.  Glad you stated them clearly.

>>    but this would spare us the cost of new syntax.
>
> On the contrary, creating a block for each keyword would mean a lot of
> new syntax.
>
> We currently have 8 types of blocks (not counting dynamic blocks, whose
> syntax is a bit different), all requiring to be parsed differently:
>
>   1. Center blocks,
>   2. Comment blocks,
>   3. Example blocks,
>   4. Export blocks,
>   5. Quote blocks,
>   6. Special blocks,
>   7. Src blocks,
>   8. Verse blocks.

I'm not sure what do you mean by "requiring to be parsed differently".
Can you explain it?  I understand they should be treated differently by
the exporters, but I don't understand why they would need to be parsed
differently.

My idea was to avoid parsing both #+html and #+begin_html.  And that 
#+begin_xxx syntax is already available for folding, which is a feature 
we might want for #+text and keywords like that.

I would suggest this rule: #+begin_ is always for _content_
while #+keyword is always for internals that are removed when 
exporting.  #+text, #+html, #+LaTeX are a few exception I can
think of.

Best,

-- 
 Bastien

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 11/3/11 2:26 AM, Bastien wrote:
> Hi Nicolas,
>
> Nicolas Goaziou<n.goaziou@gmail.com>  writes:
(...)
>> There is also "#+bind:", whose purpose is close enough.
>
> Indeed.  Eric, would it be possible to use
>
> #+bind foo 1
>
> instead of
>
> #+property var foo=1

Correct me if I'm wrong, but the purpose of #+BIND is to specify a 
file local variable, isn't it? The manual gives one example of how to 
modify export settings with it.

With Babel blocks, there should be clarity what variables are to be 
passed to the block as arguments, and what variables should not. 
Currently this is completely clear: Only variables named in a `var' 
property or header argument are passed.

Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's 
for Babel and when it's not. Say we make Babel use BIND values, and 
someone has this setup:

#+BIND: org-export-latex-low-levels itemize
#+BIND: foo 1
#+BIND: bar 2

Then this:

#+BEGIN_SRC emacs-lisp
(+ foo bar)
#+END_SRC

would tangle to something like:

(let ((org-export-latex-low-levels (guote itemize))
       (foo (quote 1))
       (bar (quote 2)))
(+ foo bar))

-- which was not the intention.

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nick Dokos]

Christian Moe <mail@christianmoe.com> wrote:

> On 11/3/11 2:26 AM, Bastien wrote:
> > Hi Nicolas,
> >
> > Nicolas Goaziou<n.goaziou@gmail.com>  writes:
> (...)
> >> There is also "#+bind:", whose purpose is close enough.
> >
> > Indeed.  Eric, would it be possible to use
> >
> > #+bind foo 1
> >
> > instead of
> >
> > #+property var foo=1
> 
> Correct me if I'm wrong, but the purpose of #+BIND is to specify a 
> file local variable, isn't it? The manual gives one example of how to 
> modify export settings with it.
> 

It's actually more restricted than that: during preprocessing, the function
org-install-letbind adds the bindings as file-locals *during export*.

> With Babel blocks, there should be clarity what variables are to be 
> passed to the block as arguments, and what variables should not. 
> Currently this is completely clear: Only variables named in a `var' 
> property or header argument are passed.
> 
> Using =#+bind foo 1= would be ambiguous; you wouldn't know when it's 
> for Babel and when it's not. Say we make Babel use BIND values, and 
> someone has this setup:
> 
> #+BIND: org-export-latex-low-levels itemize
> #+BIND: foo 1
> #+BIND: bar 2
> 
> Then this:
> 
> #+BEGIN_SRC emacs-lisp
> (+ foo bar)
> #+END_SRC
> 
> would tangle to something like:
> 
> (let ((org-export-latex-low-levels (guote itemize))
>        (foo (quote 1))
>        (bar (quote 2)))
> (+ foo bar))
> 
> -- which was not the intention.
> 

I agree - the bind namespace and the code block variable name space
should be separate. BIND was iirc Carsten's throwing up his hands
when people were asking for more and more options to be settable
from within the file: he built a general (if not particularly
convenient) mechanism to allow people to do just that.

Nick

> Yours,
> Christian
> 

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

I don't understand why the `org-accumulated-properties-alist' solution
seems like a hack, could someone elaborate.  To me that still feels like
the most natural solution.

more below...

>>> 2) "Cumulative properties"?
>>>
>>>    Here is a suggestion: use a syntaxe like
>>>  
>>>    #+var: foo 1
>>
>> There is also "#+bind:", whose purpose is close enough.
>
> Indeed.  Eric, would it be possible to use 
>
> #+bind foo 1 
>
> instead of 
>
> #+property var foo=1
>

No, this would not for subtree-level properties, i.e., in a property
block under a subtree there would be no way to tell if a property is a
#+var:.  I think if this were an approach, a more elegant solution would
be for users to customize the `org-babel-default-header-args' variable
using Emacs' file-local-variable feature -- which is possible now and
may end up being the best solution.

>
>>> 3) Wrapping/folding long #+xxx lines?
>>>
>>>    This is an independant request -- see Robert McIntyre's recent
>>>    question on the list.  The problem is that fill-paragraph on
>>>    long #+xxx lines breaks the line into comment lines, which is 
>>>    wrong.  Filling like this:
>>>
>>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>>>           : @3$2=@1$2+@2$2::...
>>>           : @3$2=@1$2+@2$2::...
>>
>> #+tblfm: ...
>> #+tblfm: ...
>> #+tblfm: ...
>
> Not very elegant, but perhaps more efficient/consistent.
>

I like this solution, especially as I have often struggled with long and
unreadable tblfm lines.  The problem with using this for property lines
would be in the case of

#+property: foo bar
#+property: baz qux

whether the above should be parsed as

  '(("foo" . "bar") ("baz" . "qux"))

or

  '(("foo" . "bar baz qux"))

>>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>>>    keywords.  This would make the current
>>>    org-internals-oriented/content-oriented difference between #+xxx
>>>    and #+begin_xxx obsolete
>>
>> I suggest to avoid such a thing. Here are a few, more or less valid,
>> reasons:
>>
>>   - That distinction is useful for the user (clear separation between
>>     contents and Org control).
>>   - It would penalize usage of special blocks.
>>   - The need is localized to very few keywords: it isn't worth the added
>>     complexity.
>>   - It would be ugly: no more nice stacking of keywords, but a mix of
>>     blocks and keywords, and blocks on top of blocks... Org syntax may
>>     not be the prettiest ever, it doesn't deserve that.
>>   - It would be a real pain to parse.
>
> Well, I agree with most of the reasons.  Glad you stated them clearly.
>

Yes, I agree some of the above are very motivating.

>
>>>    but this would spare us the cost of new syntax.
>>
>> On the contrary, creating a block for each keyword would mean a lot of
>> new syntax.
>>
>> We currently have 8 types of blocks (not counting dynamic blocks, whose
>> syntax is a bit different), all requiring to be parsed differently:
>>
>>   1. Center blocks,
>>   2. Comment blocks,
>>   3. Example blocks,
>>   4. Export blocks,
>>   5. Quote blocks,
>>   6. Special blocks,
>>   7. Src blocks,
>>   8. Verse blocks.
>
> I'm not sure what do you mean by "requiring to be parsed differently".
> Can you explain it?  I understand they should be treated differently by
> the exporters, but I don't understand why they would need to be parsed
> differently.
>

I also wouldn't think of this as new syntax, I don't see 8 rules for the
8 types above but rather one rule along the lines of #+begin_SOMETHING
where the SOMETHING can be anything.

Best -- Eric

>
> My idea was to avoid parsing both #+html and #+begin_html.  And that
> #+begin_xxx syntax is already available for folding, which is a feature 
> we might want for #+text and keywords like that.
>
> I would suggest this rule: #+begin_ is always for _content_
> while #+keyword is always for internals that are removed when 
> exporting.  #+text, #+html, #+LaTeX are a few exception I can
> think of.
>
> Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Nicolas Goaziou]

Eric Schulte <schulte.eric@gmail.com> writes:

>>> On the contrary, creating a block for each keyword would mean a lot of
>>> new syntax.
>>>
>>> We currently have 8 types of blocks (not counting dynamic blocks, whose
>>> syntax is a bit different), all requiring to be parsed differently:
>>>
>>>   1. Center blocks,
>>>   2. Comment blocks,
>>>   3. Example blocks,
>>>   4. Export blocks,
>>>   5. Quote blocks,
>>>   6. Special blocks,
>>>   7. Src blocks,
>>>   8. Verse blocks.
>>
>> I'm not sure what do you mean by "requiring to be parsed differently".
>> Can you explain it?  I understand they should be treated differently by
>> the exporters, but I don't understand why they would need to be parsed
>> differently.
>>
>
> I also wouldn't think of this as new syntax, I don't see 8 rules for the
> 8 types above but rather one rule along the lines of #+begin_SOMETHING
> where the SOMETHING can be anything.

Well, certainly, from a "Press TAB on #+begin_ line", they have exactly
the same meaning, and could as well be labelled #+begin_SOMETHING. But,

  - If I consider fontification, "Src blocks" differ from "Example
    blocks", which differ from everything else.

  - If I consider `org-edit-special', C-c ' will bring you to a buffer
    with a special mode in "Src blocks", fundamental mode in "Example
    blocks" and "Verse blocks".

  - If I consider lists, you can have them in "Quote blocks", but not in
    "Export blocks" or "Verse blocks", for example.

  - If I consider indentation, it will be ignored for "Example blocks"
    (and should do the same for "Verse blocks"), could do something
    entirely different on "Src blocks", and will indent normally,
    i.e. "Quote blocks".

  - If I consider recursion, you can have "Quote blocks" inside "Center
    blocks", but not inside "Export blocks".

  - If I consider options on the "begin_" line, "Example blocks" accept
    them, but not "Center blocks".

  - If I consider entities, you can have them in "Verse blocks" but not
    in "Example blocks"

  - If I consider export, obviously, they will all be treated very
    differently.

And I'm pretty sure I'm forgetting some other case. So, yes, from the
moon, they're pretty much indistinguishable ;) From an Org point of
view, they have 8 different meanings and, as such, need to be parsed
differently. At least, I've had to proceed that way when I wrote an Org
parser.


Regards,

-- 
Nicolas Goaziou

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Eric Schulte <schulte.eric@gmail.com> writes:
>
>>>> On the contrary, creating a block for each keyword would mean a lot of
>>>> new syntax.
>>>>
>>>> We currently have 8 types of blocks (not counting dynamic blocks, whose
>>>> syntax is a bit different), all requiring to be parsed differently:
>>>>
>>>>   1. Center blocks,
>>>>   2. Comment blocks,
>>>>   3. Example blocks,
>>>>   4. Export blocks,
>>>>   5. Quote blocks,
>>>>   6. Special blocks,
>>>>   7. Src blocks,
>>>>   8. Verse blocks.
>>>
>>> I'm not sure what do you mean by "requiring to be parsed differently".
>>> Can you explain it?  I understand they should be treated differently by
>>> the exporters, but I don't understand why they would need to be parsed
>>> differently.
>>>
>>
>> I also wouldn't think of this as new syntax, I don't see 8 rules for the
>> 8 types above but rather one rule along the lines of #+begin_SOMETHING
>> where the SOMETHING can be anything.
>
> Well, certainly, from a "Press TAB on #+begin_ line", they have exactly
> the same meaning, and could as well be labelled #+begin_SOMETHING. But,
>
>   - If I consider fontification, "Src blocks" differ from "Example
>     blocks", which differ from everything else.
>
>   - If I consider `org-edit-special', C-c ' will bring you to a buffer
>     with a special mode in "Src blocks", fundamental mode in "Example
>     blocks" and "Verse blocks".
>
>   - If I consider lists, you can have them in "Quote blocks", but not in
>     "Export blocks" or "Verse blocks", for example.
>
>   - If I consider indentation, it will be ignored for "Example blocks"
>     (and should do the same for "Verse blocks"), could do something
>     entirely different on "Src blocks", and will indent normally,
>     i.e. "Quote blocks".
>
>   - If I consider recursion, you can have "Quote blocks" inside "Center
>     blocks", but not inside "Export blocks".
>
>   - If I consider options on the "begin_" line, "Example blocks" accept
>     them, but not "Center blocks".
>
>   - If I consider entities, you can have them in "Verse blocks" but not
>     in "Example blocks"
>
>   - If I consider export, obviously, they will all be treated very
>     differently.
>
> And I'm pretty sure I'm forgetting some other case. So, yes, from the
> moon, they're pretty much indistinguishable ;) From an Org point of
> view, they have 8 different meanings and, as such, need to be parsed
> differently. At least, I've had to proceed that way when I wrote an Org
> parser.
>

Point made :), I concede a huge difference between block types.

I'm ultimately happy that the begin_property approach has not moved
forward.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

One more idea that has occurred to me, it should give all of the
functionality which we desire (i.e., the ability for a property value to
span multiple lines and to be accumulated at the subtree level), and it
should require *no* new syntax.  The only problem is it puts a
limitation on possible property names -- namely that they can not end
with the + character.

The proposal is, when a property name ends in +, the value is appended
to the corresponding property, rather than replacing it, so

  #+PROPERTY: var   foo=1
  #+PROPERTY: var   bar=2

results in '(("var" . "bar=2"))

  #+PROPERTY: var    foo=1
  #+PROPERTY: var+ , bar=2

results in '(("var" . "foo=1, bar=2"))

This way subtree properties could be used as well, e.g.,

  #+PROPERTY: var foo=1

  * subtree
    :PROPERTIES:
    :var+: bar=2
    :CUSTOM_ID: something
    :END:

Just another thought.

Best -- Eric

Eric Schulte <schulte.eric@gmail.com> writes:

> I don't understand why the `org-accumulated-properties-alist' solution
> seems like a hack, could someone elaborate.  To me that still feels like
> the most natural solution.
>
> more below...
>
>>>> 2) "Cumulative properties"?
>>>>
>>>>    Here is a suggestion: use a syntaxe like
>>>>  
>>>>    #+var: foo 1
>>>
>>> There is also "#+bind:", whose purpose is close enough.
>>
>> Indeed.  Eric, would it be possible to use 
>>
>> #+bind foo 1 
>>
>> instead of 
>>
>> #+property var foo=1
>>
>
> No, this would not for subtree-level properties, i.e., in a property
> block under a subtree there would be no way to tell if a property is a
> #+var:.  I think if this were an approach, a more elegant solution would
> be for users to customize the `org-babel-default-header-args' variable
> using Emacs' file-local-variable feature -- which is possible now and
> may end up being the best solution.
>
>>
>>>> 3) Wrapping/folding long #+xxx lines?
>>>>
>>>>    This is an independant request -- see Robert McIntyre's recent
>>>>    question on the list.  The problem is that fill-paragraph on
>>>>    long #+xxx lines breaks the line into comment lines, which is 
>>>>    wrong.  Filling like this:
>>>>
>>>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>>>>           : @3$2=@1$2+@2$2::...
>>>>           : @3$2=@1$2+@2$2::...
>>>
>>> #+tblfm: ...
>>> #+tblfm: ...
>>> #+tblfm: ...
>>
>> Not very elegant, but perhaps more efficient/consistent.
>>
>
> I like this solution, especially as I have often struggled with long and
> unreadable tblfm lines.  The problem with using this for property lines
> would be in the case of
>
> #+property: foo bar
> #+property: baz qux
>
> whether the above should be parsed as
>
>   '(("foo" . "bar") ("baz" . "qux"))
>
> or
>
>   '(("foo" . "bar baz qux"))
>
>>>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>>>>    keywords.  This would make the current
>>>>    org-internals-oriented/content-oriented difference between #+xxx
>>>>    and #+begin_xxx obsolete
>>>
>>> I suggest to avoid such a thing. Here are a few, more or less valid,
>>> reasons:
>>>
>>>   - That distinction is useful for the user (clear separation between
>>>     contents and Org control).
>>>   - It would penalize usage of special blocks.
>>>   - The need is localized to very few keywords: it isn't worth the added
>>>     complexity.
>>>   - It would be ugly: no more nice stacking of keywords, but a mix of
>>>     blocks and keywords, and blocks on top of blocks... Org syntax may
>>>     not be the prettiest ever, it doesn't deserve that.
>>>   - It would be a real pain to parse.
>>
>> Well, I agree with most of the reasons.  Glad you stated them clearly.
>>
>
> Yes, I agree some of the above are very motivating.
>
>>
>>>>    but this would spare us the cost of new syntax.
>>>
>>> On the contrary, creating a block for each keyword would mean a lot of
>>> new syntax.
>>>
>>> We currently have 8 types of blocks (not counting dynamic blocks, whose
>>> syntax is a bit different), all requiring to be parsed differently:
>>>
>>>   1. Center blocks,
>>>   2. Comment blocks,
>>>   3. Example blocks,
>>>   4. Export blocks,
>>>   5. Quote blocks,
>>>   6. Special blocks,
>>>   7. Src blocks,
>>>   8. Verse blocks.
>>
>> I'm not sure what do you mean by "requiring to be parsed differently".
>> Can you explain it?  I understand they should be treated differently by
>> the exporters, but I don't understand why they would need to be parsed
>> differently.
>>
>
> I also wouldn't think of this as new syntax, I don't see 8 rules for the
> 8 types above but rather one rule along the lines of #+begin_SOMETHING
> where the SOMETHING can be anything.
>
> Best -- Eric
>
>>
>> My idea was to avoid parsing both #+html and #+begin_html.  And that
>> #+begin_xxx syntax is already available for folding, which is a feature 
>> we might want for #+text and keywords like that.
>>
>> I would suggest this rule: #+begin_ is always for _content_
>> while #+keyword is always for internals that are removed when 
>> exporting.  #+text, #+html, #+LaTeX are a few exception I can
>> think of.
>>
>> Best,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 6160 bytes --]

On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte <schulte.eric@gmail.com> wrote:

> One more idea that has occurred to me, it should give all of the
> functionality which we desire (i.e., the ability for a property value to
> span multiple lines and to be accumulated at the subtree level), and it
> should require *no* new syntax.  The only problem is it puts a
> limitation on possible property names -- namely that they can not end
> with the + character.
>
> The proposal is, when a property name ends in +, the value is appended
> to the corresponding property, rather than replacing it, so
>
>  #+PROPERTY: var   foo=1
>  #+PROPERTY: var   bar=2
>
> results in '(("var" . "bar=2"))
>
>  #+PROPERTY: var    foo=1
>  #+PROPERTY: var+ , bar=2
>
> results in '(("var" . "foo=1, bar=2"))
>
> This way subtree properties could be used as well, e.g.,
>
>  #+PROPERTY: var foo=1
>
>  * subtree
>    :PROPERTIES:
>    :var+: bar=2
>    :CUSTOM_ID: something
>    :END:
>
> Just another thought.
>

I like that suggestion - it is clear, easy to understand, gives other
advantages (you can "unset" variables in a subtree - which would be an
added bonus) and does not require any large changes in org files.

This suggestion would get my vote.

Cheers,

Rainer




> Best -- Eric
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
> > I don't understand why the `org-accumulated-properties-alist' solution
> > seems like a hack, could someone elaborate.  To me that still feels like
> > the most natural solution.
> >
> > more below...
> >
> >>>> 2) "Cumulative properties"?
> >>>>
> >>>>    Here is a suggestion: use a syntaxe like
> >>>>
> >>>>    #+var: foo 1
> >>>
> >>> There is also "#+bind:", whose purpose is close enough.
> >>
> >> Indeed.  Eric, would it be possible to use
> >>
> >> #+bind foo 1
> >>
> >> instead of
> >>
> >> #+property var foo=1
> >>
> >
> > No, this would not for subtree-level properties, i.e., in a property
> > block under a subtree there would be no way to tell if a property is a
> > #+var:.  I think if this were an approach, a more elegant solution would
> > be for users to customize the `org-babel-default-header-args' variable
> > using Emacs' file-local-variable feature -- which is possible now and
> > may end up being the best solution.
> >
> >>
> >>>> 3) Wrapping/folding long #+xxx lines?
> >>>>
> >>>>    This is an independant request -- see Robert McIntyre's recent
> >>>>    question on the list.  The problem is that fill-paragraph on
> >>>>    long #+xxx lines breaks the line into comment lines, which is
> >>>>    wrong.  Filling like this:
> >>>>
> >>>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
> >>>>           : @3$2=@1$2+@2$2::...
> >>>>           : @3$2=@1$2+@2$2::...
> >>>
> >>> #+tblfm: ...
> >>> #+tblfm: ...
> >>> #+tblfm: ...
> >>
> >> Not very elegant, but perhaps more efficient/consistent.
> >>
> >
> > I like this solution, especially as I have often struggled with long and
> > unreadable tblfm lines.  The problem with using this for property lines
> > would be in the case of
> >
> > #+property: foo bar
> > #+property: baz qux
> >
> > whether the above should be parsed as
> >
> >   '(("foo" . "bar") ("baz" . "qux"))
> >
> > or
> >
> >   '(("foo" . "bar baz qux"))
> >
> >>>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
> >>>>    keywords.  This would make the current
> >>>>    org-internals-oriented/content-oriented difference between #+xxx
> >>>>    and #+begin_xxx obsolete
> >>>
> >>> I suggest to avoid such a thing. Here are a few, more or less valid,
> >>> reasons:
> >>>
> >>>   - That distinction is useful for the user (clear separation between
> >>>     contents and Org control).
> >>>   - It would penalize usage of special blocks.
> >>>   - The need is localized to very few keywords: it isn't worth the
> added
> >>>     complexity.
> >>>   - It would be ugly: no more nice stacking of keywords, but a mix of
> >>>     blocks and keywords, and blocks on top of blocks... Org syntax may
> >>>     not be the prettiest ever, it doesn't deserve that.
> >>>   - It would be a real pain to parse.
> >>
> >> Well, I agree with most of the reasons.  Glad you stated them clearly.
> >>
> >
> > Yes, I agree some of the above are very motivating.
> >
> >>
> >>>>    but this would spare us the cost of new syntax.
> >>>
> >>> On the contrary, creating a block for each keyword would mean a lot of
> >>> new syntax.
> >>>
> >>> We currently have 8 types of blocks (not counting dynamic blocks, whose
> >>> syntax is a bit different), all requiring to be parsed differently:
> >>>
> >>>   1. Center blocks,
> >>>   2. Comment blocks,
> >>>   3. Example blocks,
> >>>   4. Export blocks,
> >>>   5. Quote blocks,
> >>>   6. Special blocks,
> >>>   7. Src blocks,
> >>>   8. Verse blocks.
> >>
> >> I'm not sure what do you mean by "requiring to be parsed differently".
> >> Can you explain it?  I understand they should be treated differently by
> >> the exporters, but I don't understand why they would need to be parsed
> >> differently.
> >>
> >
> > I also wouldn't think of this as new syntax, I don't see 8 rules for the
> > 8 types above but rather one rule along the lines of #+begin_SOMETHING
> > where the SOMETHING can be anything.
> >
> > Best -- Eric
> >
> >>
> >> My idea was to avoid parsing both #+html and #+begin_html.  And that
> >> #+begin_xxx syntax is already available for folding, which is a feature
> >> we might want for #+text and keywords like that.
> >>
> >> I would suggest this rule: #+begin_ is always for _content_
> >> while #+keyword is always for internals that are removed when
> >> exporting.  #+text, #+html, #+LaTeX are a few exception I can
> >> think of.
> >>
> >> Best,
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 8468 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Darlan Cavalcante Moreira]

I liked this suggestion. In a sense, it is similar to the "inherit" keyword
I had suggested before, but now the "keyword" (the plus sign) is part of
the variable name. 

But the reason I really liked it is because it is clear to understand. One
can compare it to the "+=" operator some languages have. That is, we can understand `:var: bar=2` as var="bar=2" and `:var+: bar=2` as
var+="bar=2".`

--
Darlan

At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug <r.m.krug@gmail.com>
wrote:
> 
> On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
> 
> > One more idea that has occurred to me, it should give all of the
> > functionality which we desire (i.e., the ability for a property value to
> > span multiple lines and to be accumulated at the subtree level), and it
> > should require *no* new syntax.  The only problem is it puts a
> > limitation on possible property names -- namely that they can not end
> > with the + character.
> >
> > The proposal is, when a property name ends in +, the value is appended
> > to the corresponding property, rather than replacing it, so
> >
> >  #+PROPERTY: var   foo=1
> >  #+PROPERTY: var   bar=2
> >
> > results in '(("var" . "bar=2"))
> >
> >  #+PROPERTY: var    foo=1
> >  #+PROPERTY: var+ , bar=2
> >
> > results in '(("var" . "foo=1, bar=2"))
> >
> > This way subtree properties could be used as well, e.g.,
> >
> >  #+PROPERTY: var foo=1
> >
> >  * subtree
> >    :PROPERTIES:
> >    :var+: bar=2
> >    :CUSTOM_ID: something
> >    :END:
> >
> > Just another thought.
> >
> 
> I like that suggestion - it is clear, easy to understand, gives other
> advantages (you can "unset" variables in a subtree - which would be an
> added bonus) and does not require any large changes in org files.
> 
> This suggestion would get my vote.
> 
> Cheers,
> 
> Rainer
> 
> 
> 
> 
> > Best -- Eric
> >
> > Eric Schulte <schulte.eric@gmail.com> writes:
> >
> > > I don't understand why the `org-accumulated-properties-alist' solution
> > > seems like a hack, could someone elaborate.  To me that still feels like
> > > the most natural solution.
> > >
> > > more below...
> > >
> > >>>> 2) "Cumulative properties"?
> > >>>>
> > >>>>    Here is a suggestion: use a syntaxe like
> > >>>>
> > >>>>    #+var: foo 1
> > >>>
> > >>> There is also "#+bind:", whose purpose is close enough.
> > >>
> > >> Indeed.  Eric, would it be possible to use
> > >>
> > >> #+bind foo 1
> > >>
> > >> instead of
> > >>
> > >> #+property var foo=1
> > >>
> > >
> > > No, this would not for subtree-level properties, i.e., in a property
> > > block under a subtree there would be no way to tell if a property is a
> > > #+var:.  I think if this were an approach, a more elegant solution would
> > > be for users to customize the `org-babel-default-header-args' variable
> > > using Emacs' file-local-variable feature -- which is possible now and
> > > may end up being the best solution.
> > >
> > >>
> > >>>> 3) Wrapping/folding long #+xxx lines?
> > >>>>
> > >>>>    This is an independant request -- see Robert McIntyre's recent
> > >>>>    question on the list.  The problem is that fill-paragraph on
> > >>>>    long #+xxx lines breaks the line into comment lines, which is
> > >>>>    wrong.  Filling like this:
> > >>>>
> > >>>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
> > >>>>           : @3$2=@1$2+@2$2::...
> > >>>>           : @3$2=@1$2+@2$2::...
> > >>>
> > >>> #+tblfm: ...
> > >>> #+tblfm: ...
> > >>> #+tblfm: ...
> > >>
> > >> Not very elegant, but perhaps more efficient/consistent.
> > >>
> > >
> > > I like this solution, especially as I have often struggled with long and
> > > unreadable tblfm lines.  The problem with using this for property lines
> > > would be in the case of
> > >
> > > #+property: foo bar
> > > #+property: baz qux
> > >
> > > whether the above should be parsed as
> > >
> > >   '(("foo" . "bar") ("baz" . "qux"))
> > >
> > > or
> > >
> > >   '(("foo" . "bar baz qux"))
> > >
> > >>>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
> > >>>>    keywords.  This would make the current
> > >>>>    org-internals-oriented/content-oriented difference between #+xxx
> > >>>>    and #+begin_xxx obsolete
> > >>>
> > >>> I suggest to avoid such a thing. Here are a few, more or less valid,
> > >>> reasons:
> > >>>
> > >>>   - That distinction is useful for the user (clear separation between
> > >>>     contents and Org control).
> > >>>   - It would penalize usage of special blocks.
> > >>>   - The need is localized to very few keywords: it isn't worth the
> > added
> > >>>     complexity.
> > >>>   - It would be ugly: no more nice stacking of keywords, but a mix of
> > >>>     blocks and keywords, and blocks on top of blocks... Org syntax may
> > >>>     not be the prettiest ever, it doesn't deserve that.
> > >>>   - It would be a real pain to parse.
> > >>
> > >> Well, I agree with most of the reasons.  Glad you stated them clearly.
> > >>
> > >
> > > Yes, I agree some of the above are very motivating.
> > >
> > >>
> > >>>>    but this would spare us the cost of new syntax.
> > >>>
> > >>> On the contrary, creating a block for each keyword would mean a lot of
> > >>> new syntax.
> > >>>
> > >>> We currently have 8 types of blocks (not counting dynamic blocks, whose
> > >>> syntax is a bit different), all requiring to be parsed differently:
> > >>>
> > >>>   1. Center blocks,
> > >>>   2. Comment blocks,
> > >>>   3. Example blocks,
> > >>>   4. Export blocks,
> > >>>   5. Quote blocks,
> > >>>   6. Special blocks,
> > >>>   7. Src blocks,
> > >>>   8. Verse blocks.
> > >>
> > >> I'm not sure what do you mean by "requiring to be parsed differently".
> > >> Can you explain it?  I understand they should be treated differently by
> > >> the exporters, but I don't understand why they would need to be parsed
> > >> differently.
> > >>
> > >
> > > I also wouldn't think of this as new syntax, I don't see 8 rules for the
> > > 8 types above but rather one rule along the lines of #+begin_SOMETHING
> > > where the SOMETHING can be anything.
> > >
> > > Best -- Eric
> > >
> > >>
> > >> My idea was to avoid parsing both #+html and #+begin_html.  And that
> > >> #+begin_xxx syntax is already available for folding, which is a feature
> > >> we might want for #+text and keywords like that.
> > >>
> > >> I would suggest this rule: #+begin_ is always for _content_
> > >> while #+keyword is always for internals that are removed when
> > >> exporting.  #+text, #+html, #+LaTeX are a few exception I can
> > >> think of.
> > >>
> > >> Best,
> >
> > --
> > Eric Schulte
> > http://cs.unm.edu/~eschulte/
> >
> >
> 
> 
> -- 
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
> 
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
> 
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax (F):       +33 - (0)9 58 10 27 44
> 
> Fax (D):    +49 - (0)3 21 21 25 22 44
> 
> email:      Rainer@krugs.de
> 
> Skype:      RMkrug

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Darlan Cavalcante Moreira <darcamo@gmail.com> writes:

> I liked this suggestion. In a sense, it is similar to the "inherit" keyword
> I had suggested before, but now the "keyword" (the plus sign) is part of
> the variable name. 
>

Oh yes, I didn't realize that when I first posted this suggestion but it
is very similar to your suggested "inherit" keyword,

>
> But the reason I really liked it is because it is clear to
> understand. One can compare it to the "+=" operator some languages
> have. That is, we can understand `:var: bar=2` as var="bar=2" and
> `:var+: bar=2` as var+="bar=2".`
>

Agreed, it was the limitation of possible values which I didn't like
about your "inherit" suggestion, but this approach switches the
limitation to the property name rather than the property value which is
somehow more appealing.

Cheers -- Eric

>
> --
> Darlan
>
> At Fri, 4 Nov 2011 09:02:43 +0100, Rainer M Krug <r.m.krug@gmail.com>
> wrote:
>> 
>> On Thu, Nov 3, 2011 at 9:23 PM, Eric Schulte <schulte.eric@gmail.com> wrote:
>> 
>> > One more idea that has occurred to me, it should give all of the
>> > functionality which we desire (i.e., the ability for a property value to
>> > span multiple lines and to be accumulated at the subtree level), and it
>> > should require *no* new syntax.  The only problem is it puts a
>> > limitation on possible property names -- namely that they can not end
>> > with the + character.
>> >
>> > The proposal is, when a property name ends in +, the value is appended
>> > to the corresponding property, rather than replacing it, so
>> >
>> >  #+PROPERTY: var   foo=1
>> >  #+PROPERTY: var   bar=2
>> >
>> > results in '(("var" . "bar=2"))
>> >
>> >  #+PROPERTY: var    foo=1
>> >  #+PROPERTY: var+ , bar=2
>> >
>> > results in '(("var" . "foo=1, bar=2"))
>> >
>> > This way subtree properties could be used as well, e.g.,
>> >
>> >  #+PROPERTY: var foo=1
>> >
>> >  * subtree
>> >    :PROPERTIES:
>> >    :var+: bar=2
>> >    :CUSTOM_ID: something
>> >    :END:
>> >
>> > Just another thought.
>> >
>> 
>> I like that suggestion - it is clear, easy to understand, gives other
>> advantages (you can "unset" variables in a subtree - which would be an
>> added bonus) and does not require any large changes in org files.
>> 
>> This suggestion would get my vote.
>> 
>> Cheers,
>> 
>> Rainer
>> 
>> 
>> 
>> 
>> > Best -- Eric
>> >
>> > Eric Schulte <schulte.eric@gmail.com> writes:
>> >
>> > > I don't understand why the `org-accumulated-properties-alist' solution
>> > > seems like a hack, could someone elaborate.  To me that still feels like
>> > > the most natural solution.
>> > >
>> > > more below...
>> > >
>> > >>>> 2) "Cumulative properties"?
>> > >>>>
>> > >>>>    Here is a suggestion: use a syntaxe like
>> > >>>>
>> > >>>>    #+var: foo 1
>> > >>>
>> > >>> There is also "#+bind:", whose purpose is close enough.
>> > >>
>> > >> Indeed.  Eric, would it be possible to use
>> > >>
>> > >> #+bind foo 1
>> > >>
>> > >> instead of
>> > >>
>> > >> #+property var foo=1
>> > >>
>> > >
>> > > No, this would not for subtree-level properties, i.e., in a property
>> > > block under a subtree there would be no way to tell if a property is a
>> > > #+var:.  I think if this were an approach, a more elegant solution would
>> > > be for users to customize the `org-babel-default-header-args' variable
>> > > using Emacs' file-local-variable feature -- which is possible now and
>> > > may end up being the best solution.
>> > >
>> > >>
>> > >>>> 3) Wrapping/folding long #+xxx lines?
>> > >>>>
>> > >>>>    This is an independant request -- see Robert McIntyre's recent
>> > >>>>    question on the list.  The problem is that fill-paragraph on
>> > >>>>    long #+xxx lines breaks the line into comment lines, which is
>> > >>>>    wrong.  Filling like this:
>> > >>>>
>> > >>>>    #+TBLFM: @3$1=@1$1+@2$1::@3$2=@1$2+@2$2::...::...
>> > >>>>           : @3$2=@1$2+@2$2::...
>> > >>>>           : @3$2=@1$2+@2$2::...
>> > >>>
>> > >>> #+tblfm: ...
>> > >>> #+tblfm: ...
>> > >>> #+tblfm: ...
>> > >>
>> > >> Not very elegant, but perhaps more efficient/consistent.
>> > >>
>> > >
>> > > I like this solution, especially as I have often struggled with long and
>> > > unreadable tblfm lines.  The problem with using this for property lines
>> > > would be in the case of
>> > >
>> > > #+property: foo bar
>> > > #+property: baz qux
>> > >
>> > > whether the above should be parsed as
>> > >
>> > >   '(("foo" . "bar") ("baz" . "qux"))
>> > >
>> > > or
>> > >
>> > >   '(("foo" . "bar baz qux"))
>> > >
>> > >>>>    But maybe generalizing the #+begin_xxx syntax for *all* #+xxx
>> > >>>>    keywords.  This would make the current
>> > >>>>    org-internals-oriented/content-oriented difference between #+xxx
>> > >>>>    and #+begin_xxx obsolete
>> > >>>
>> > >>> I suggest to avoid such a thing. Here are a few, more or less valid,
>> > >>> reasons:
>> > >>>
>> > >>>   - That distinction is useful for the user (clear separation between
>> > >>>     contents and Org control).
>> > >>>   - It would penalize usage of special blocks.
>> > >>>   - The need is localized to very few keywords: it isn't worth the
>> > added
>> > >>>     complexity.
>> > >>>   - It would be ugly: no more nice stacking of keywords, but a mix of
>> > >>>     blocks and keywords, and blocks on top of blocks... Org syntax may
>> > >>>     not be the prettiest ever, it doesn't deserve that.
>> > >>>   - It would be a real pain to parse.
>> > >>
>> > >> Well, I agree with most of the reasons.  Glad you stated them clearly.
>> > >>
>> > >
>> > > Yes, I agree some of the above are very motivating.
>> > >
>> > >>
>> > >>>>    but this would spare us the cost of new syntax.
>> > >>>
>> > >>> On the contrary, creating a block for each keyword would mean a lot of
>> > >>> new syntax.
>> > >>>
>> > >>> We currently have 8 types of blocks (not counting dynamic blocks, whose
>> > >>> syntax is a bit different), all requiring to be parsed differently:
>> > >>>
>> > >>>   1. Center blocks,
>> > >>>   2. Comment blocks,
>> > >>>   3. Example blocks,
>> > >>>   4. Export blocks,
>> > >>>   5. Quote blocks,
>> > >>>   6. Special blocks,
>> > >>>   7. Src blocks,
>> > >>>   8. Verse blocks.
>> > >>
>> > >> I'm not sure what do you mean by "requiring to be parsed differently".
>> > >> Can you explain it?  I understand they should be treated differently by
>> > >> the exporters, but I don't understand why they would need to be parsed
>> > >> differently.
>> > >>
>> > >
>> > > I also wouldn't think of this as new syntax, I don't see 8 rules for the
>> > > 8 types above but rather one rule along the lines of #+begin_SOMETHING
>> > > where the SOMETHING can be anything.
>> > >
>> > > Best -- Eric
>> > >
>> > >>
>> > >> My idea was to avoid parsing both #+html and #+begin_html.  And that
>> > >> #+begin_xxx syntax is already available for folding, which is a feature
>> > >> we might want for #+text and keywords like that.
>> > >>
>> > >> I would suggest this rule: #+begin_ is always for _content_
>> > >> while #+keyword is always for internals that are removed when
>> > >> exporting.  #+text, #+html, #+LaTeX are a few exception I can
>> > >> think of.
>> > >>
>> > >> Best,
>> >
>> > --
>> > Eric Schulte
>> > http://cs.unm.edu/~eschulte/
>> >
>> >
>> 
>> 
>> -- 
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
>> UCT), Dipl. Phys. (Germany)
>> 
>> Centre of Excellence for Invasion Biology
>> Stellenbosch University
>> South Africa
>> 
>> Tel :       +33 - (0)9 53 10 27 44
>> Cell:       +33 - (0)6 85 62 59 98
>> Fax (F):       +33 - (0)9 58 10 27 44
>> 
>> Fax (D):    +49 - (0)3 21 21 25 22 44
>> 
>> email:      Rainer@krugs.de
>> 
>> Skype:      RMkrug

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

The attached patch implements this latest "propname+" suggestion.  When
applied it results in the behavior shown below.

I'm inclined to go with this as a solution moving forward.

Thoughts?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: something.org --]
[-- Type: text/x-org, Size: 683 bytes --]

#+property: var    foo=1
#+property: var+ , bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1, bar=2

* overwriting a file-wide property
  :PROPERTIES:
  :var:      foo=7
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 7

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=7

* appending to a file-wide property
  :PROPERTIES:
  :var+:      , baz=3
  :END:

#+begin_src emacs-lisp
  (+ foo bar baz)
#+end_src

#+results:
: 6

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1, bar=2, baz=3

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-property-names-ending-in-plus-accumulate.patch --]
[-- Type: text/x-diff, Size: 10799 bytes --]

From 1bb2009c419e5ae6c912e863b13cb02a1f1ea720 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Mon, 7 Nov 2011 14:49:42 -0700
Subject: [PATCH] property names ending in plus accumulate

This results in the following behavior.

  #+property: var    foo=1
  #+property: var+ , bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2

  * overwriting a file-wide property
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=7

  * appending to a file-wide property
    :PROPERTIES:
    :var+:      , baz=3
    :END:

  #+begin_src emacs-lisp
    (+ foo bar baz)
  #+end_src

  #+results:
  : 6

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2, baz=3

* lisp/org.el (org-update-property-plist): Updates a given property
  list with a property name and a property value.
  (org-set-regexps-and-options): Use org-update-property-plist.
  (org-entry-get): Use org-update-property-plist.
* testing/examples/property-inheritance.org: Example file for testing
  appending property behavior.
* testing/lisp/test-property-inheritance.el: Tests of appending
  property behavior.
properties with names ending in "+" accumulate rather than overwrite

This results in the following behavior.

  #+property: var    foo=1
  #+property: var+ , bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2

  * overwriting a file-wide property
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=7

  * appending to a file-wide property
    :PROPERTIES:
    :var+:      , baz=3
    :END:

  #+begin_src emacs-lisp
    (+ foo bar baz)
  #+end_src

  #+results:
  : 6

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2, baz=3

* lisp/org.el (org-update-property-plist): Updates a given property
  list with a property name and a property value.
  (org-set-regexps-and-options): Use org-update-property-plist.
  (org-entry-get): Use org-update-property-plist.
* testing/examples/property-inheritance.org: Example file for testing
  appending property behavior.
* testing/lisp/test-property-inheritance.el: Tests of appending
  property behavior.
properties with names ending in "+" accumulate rather than overwrite

This results in the following behavior.

  #+property: var    foo=1
  #+property: var+ , bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2

  * overwriting a file-wide property
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=7

  * appending to a file-wide property
    :PROPERTIES:
    :var+:      , baz=3
    :END:

  #+begin_src emacs-lisp
    (+ foo bar baz)
  #+end_src

  #+results:
  : 6

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1, bar=2, baz=3

* lisp/org.el (org-update-property-plist): Updates a given property
  list with a property name and a property value.
  (org-set-regexps-and-options): Use org-update-property-plist.
  (org-entry-get): Use org-update-property-plist.
* testing/examples/property-inheritance.org: Example file for testing
  appending property behavior.
* testing/lisp/test-property-inheritance.el: Tests of appending
  property behavior.
---
 lisp/org.el                               |   47 +++++++++++++++-------
 testing/examples/property-inheritance.org |   36 +++++++++++++++++
 testing/lisp/test-property-inheritance.el |   62 +++++++++++++++++++++++++++++
 3 files changed, 130 insertions(+), 15 deletions(-)
 create mode 100644 testing/examples/property-inheritance.org
 create mode 100644 testing/lisp/test-property-inheritance.el

diff --git a/lisp/org.el b/lisp/org.el
index 92ced78..8739ee0 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4437,6 +4437,15 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.")
 
+(defun org-update-property-plist (key val props)
+  "Update PROPS with KEY and VAL."
+  (if (string= "+" (substring key (- (length key) 1)))
+      (let* ((key (substring key 0 (- (length key) 1)))
+	     (previous (cdr (assoc key props))))
+	(cons (cons key (concat previous val))
+	      (org-remove-if (lambda (p) (string= (car p) key)) props)))
+    (cons (cons key val) props)))
+
 (defun org-set-regexps-and-options ()
   "Precompute regular expressions for current buffer."
   (when (eq major-mode 'org-mode)
@@ -4498,8 +4507,9 @@ means to push this value onto the list in the variable.")
 	      (setq prio (org-split-string value " +")))
 	     ((equal key "PROPERTY")
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props)))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props))))
 	     ((equal key "FILETAGS")
 	      (when (string-match "\\S-" value)
 		(setq ftags
@@ -4551,8 +4561,9 @@ means to push this value onto the list in the variable.")
 	      (setq value (replace-regexp-in-string
 			   "[\n\r]" " " (match-string 4)))
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props))))))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props)))))))
       (org-set-local 'org-use-sub-superscripts scripts)
       (when cat
 	(org-set-local 'org-category (intern cat))
@@ -14082,17 +14093,23 @@ when a \"nil\" value can supersede a non-nil value higher up the hierarchy."
 	  (cdr (assoc property (org-entry-properties nil 'special property)))
 	(let ((range (unless (org-before-first-heading-p)
 		       (org-get-property-block))))
-	  (if (and range
-		   (goto-char (car range))
-		   (re-search-forward
-		    (org-re-property property)
-		    (cdr range) t))
-	      ;; Found the property, return it.
-	      (if (match-end 1)
-		  (if literal-nil
-		      (org-match-string-no-properties 1)
-		    (org-not-nil (org-match-string-no-properties 1)))
-		"")))))))
+	  (when (and range (goto-char (car range)))
+	    ((lambda (val) (when val (if literal-nil val (org-not-nil val))))
+	     (cond
+	      ((re-search-forward
+		(org-re-property property) (cdr range) t)
+	       (if (match-end 1) (org-match-string-no-properties 1) ""))
+	      ((re-search-forward
+		(org-re-property (concat property "+")) (cdr range) t)
+	       (cdr (assoc
+		     property
+		     (org-update-property-plist
+		      (concat property "+")
+		      (if (match-end 1) (org-match-string-no-properties 1) "")
+		      (list (or (assoc property org-file-properties)
+				(assoc property org-global-properties)
+				(assoc property org-global-properties-fixed)
+				))))))))))))))
 
 (defun org-property-or-variable-value (var &optional inherit)
   "Check if there is a property fixing the value of VAR.
diff --git a/testing/examples/property-inheritance.org b/testing/examples/property-inheritance.org
new file mode 100644
index 0000000..b19ed6a
--- /dev/null
+++ b/testing/examples/property-inheritance.org
@@ -0,0 +1,36 @@
+#+property: var    foo=1
+#+property: var+ , bar=2
+
+#+begin_src emacs-lisp
+  (+ foo bar)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* overwriting a file-wide property
+  :PROPERTIES:
+  :var:      foo=7
+  :END:
+
+#+begin_src emacs-lisp
+  foo
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* appending to a file-wide property
+  :PROPERTIES:
+  :var+:      , baz=3
+  :END:
+
+#+begin_src emacs-lisp
+  (+ foo bar baz)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
diff --git a/testing/lisp/test-property-inheritance.el b/testing/lisp/test-property-inheritance.el
new file mode 100644
index 0000000..6bbb0f7
--- /dev/null
+++ b/testing/lisp/test-property-inheritance.el
@@ -0,0 +1,62 @@
+;;; test-ob-R.el --- tests for ob-R.el
+
+;; Copyright (c) 2011 Eric Schulte
+;; Authors: Eric Schulte
+
+;; Released under the GNU General Public License version 3
+;; see: http://www.gnu.org/licenses/gpl-3.0.html
+
+(let ((load-path (cons (expand-file-name
+			".." (file-name-directory
+			      (or load-file-name buffer-file-name)))
+		       load-path)))
+  (require 'org-test)
+  (require 'org-test-ob-consts))
+
+(defmacro test-org-in-property-buffer (&rest body)
+  `(with-temp-buffer
+     (insert-file-contents (expand-file-name "property-inheritance.org"
+					     org-test-example-dir))
+     (org-mode)
+     ,@body))
+
+(ert-deftest test-org-property-accumulation-top-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 1)
+   (should (equal 3 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-top-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 2)
+   (should (string= "foo=1, bar=2" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 3)
+   (should (= 7 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 4)
+   (should (string= "foo=7" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 5)
+   (should (= 6 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 6)
+   (should (string= "foo=1, bar=2, baz=3" (org-babel-execute-src-block)))))
+
+(provide 'test-ob-R)
+
+;;; test-ob-R.el ends here
+ 
-- 
1.7.4.1


[-- Attachment #4: Type: text/plain, Size: 47 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

On Mon, Nov 7, 2011 at 11:09 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> The attached patch implements this latest "propname+" suggestion.  When
> applied it results in the behavior shown below.
>
> I'm inclined to go with this as a solution moving forward.
>
> Thoughts?
>

Go for it - looks like a really good way of doing it.

Cheers,

Rainer


>
>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 1457 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Sebastien Vauban]

Hi Eric,

(Due to a high "buzyness" level, I've been a bit out of the discussion for one
week or so)

Eric Schulte wrote:
> The attached patch implements this latest "propname+" suggestion.  When
> applied it results in the behavior shown below.
>
> I'm inclined to go with this as a solution moving forward.
>
> Thoughts?
>
> #+property: var    foo=1
> #+property: var+ , bar=2
> #+begin_src emacs-lisp
>   (+ foo bar)
> #+end_src

So, in a way, adding the + after `var' is how you tell Org that this is an
accumulated property?

Two questions:

1. Why not the + after the property keyword (property+)? I guess because it's
   more against other aspects of Org internals?  Anyway, putting + after the
   var sounds as right to me -- maybe better even if we consider that you
   declare var as accumulated, writing so.

2. Must there be a first `var' without `+'?  Accepted, tolerated or wrong?  I
   mean, I'm sure that, due to heavy file editing, we'll sometimes have:

   #+property: var+   foo=1
   #+property: var+ , bar=2
   #+begin_src emacs-lisp
     (+ foo bar)
   #+end_src

> #+results:
> : 3
>
> #+begin_src emacs-lisp
>   (org-entry-get (point) "var" t)
> #+end_src
>
> #+results:
> : foo=1, bar=2
>
> * overwriting a file-wide property
>   :PROPERTIES:
>   :var:      foo=7
>   :END:
>
> #+begin_src emacs-lisp
>   foo
> #+end_src
>
> #+results:
> : 7
>
> #+begin_src emacs-lisp
>   (org-entry-get (point) "var" t)
> #+end_src
>
> #+results:
> : foo=7
>
> * appending to a file-wide property
>   :PROPERTIES:
>   :var+:      , baz=3
>   :END:

To be honest, the only thing that I dislike is the comma in the above line.
Not intuitive at all. Quite hard to read.

Can't the comma be implicitly added by the `+' after the property name?

That would allow one to simply write:

   * appending to a file-wide property
     :PROPERTIES:
     :var+:        baz=3
     :END:

and have the correct values.

> #+begin_src emacs-lisp
>   (+ foo bar baz)
> #+end_src
>
> #+results:
> : 6
>
> #+begin_src emacs-lisp
>   (org-entry-get (point) "var" t)
> #+end_src
>
> #+results:
> : foo=1, bar=2, baz=3

Thanks.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3212 bytes --]

On Tue, Nov 8, 2011 at 10:31 AM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Eric,
>
> (Due to a high "buzyness" level, I've been a bit out of the discussion for
> one
> week or so)
>
> Eric Schulte wrote:
> > The attached patch implements this latest "propname+" suggestion.  When
> > applied it results in the behavior shown below.
> >
> > I'm inclined to go with this as a solution moving forward.
> >
> > Thoughts?
> >
> > #+property: var    foo=1
> > #+property: var+ , bar=2
> > #+begin_src emacs-lisp
> >   (+ foo bar)
> > #+end_src
>
> So, in a way, adding the + after `var' is how you tell Org that this is an
> accumulated property?
>
> Two questions:
>
> 1. Why not the + after the property keyword (property+)? I guess because
> it's
>   more against other aspects of Org internals?  Anyway, putting + after the
>   var sounds as right to me -- maybe better even if we consider that you
>   declare var as accumulated, writing so.
>
> 2. Must there be a first `var' without `+'?  Accepted, tolerated or wrong?
>  I
>   mean, I'm sure that, due to heavy file editing, we'll sometimes have:
>

Might be a good idea to tolerate this.


>
>   #+property: var+   foo=1
>   #+property: var+ , bar=2
>   #+begin_src emacs-lisp
>     (+ foo bar)
>   #+end_src
>
> > #+results:
> > : 3
> >
> > #+begin_src emacs-lisp
> >   (org-entry-get (point) "var" t)
> > #+end_src
> >
> > #+results:
> > : foo=1, bar=2
> >
> > * overwriting a file-wide property
> >   :PROPERTIES:
> >   :var:      foo=7
> >   :END:
> >
> > #+begin_src emacs-lisp
> >   foo
> > #+end_src
> >
> > #+results:
> > : 7
> >
> > #+begin_src emacs-lisp
> >   (org-entry-get (point) "var" t)
> > #+end_src
> >
> > #+results:
> > : foo=7
> >
> > * appending to a file-wide property
> >   :PROPERTIES:
> >   :var+:      , baz=3
> >   :END:
>
> To be honest, the only thing that I dislike is the comma in the above line.
> Not intuitive at all. Quite hard to read.
>
> Can't the comma be implicitly added by the `+' after the property name?
>

On the one hand, it might have one additional advantage:

  #+property: var   foo="This is a very long text"
  #+property: var+ "with even more."

Would foo be:
"This is a very long text with even more"

Could one make the "," implicit, if the value follows the

x=y

style, while otherwise just concatenate the value to the one before?




> That would allow one to simply write:
>
>   * appending to a file-wide property
>     :PROPERTIES:
>     :var+:        baz=3
>     :END:
>
> and have the correct values.
>
> > #+begin_src emacs-lisp
> >   (+ foo bar baz)
> > #+end_src
> >
> > #+results:
> > : 6
> >
> > #+begin_src emacs-lisp
> >   (org-entry-get (point) "var" t)
> > #+end_src
> >
> > #+results:
> > : foo=1, bar=2, baz=3
>
> Thanks.
>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 4704 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Sebastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
>> > * appending to a file-wide property
>> >   :PROPERTIES:
>> >   :var+:      , baz=3
>> >   :END:
>>
>> To be honest, the only thing that I dislike is the comma in the above line.
>> Not intuitive at all. Quite hard to read.
>>
>> Can't the comma be implicitly added by the `+' after the property name?
>
> On the one hand, it might have one additional advantage:
>
>   #+property: var   foo="This is a very long text"
>   #+property: var+ "with even more."

I don't think such a construction would be tolerated. I guess you must write
a var name (foo, bar, baz, ...) after the `var+' keyword.

> Would foo be:
> "This is a very long text with even more"

To be accurate, it would have become:

  "This is a very long textwith even more"

if such a concatenation would be implied.

> Could one make the "," implicit, if the value follows the
>
> x=y
>
> style, while otherwise just concatenate the value to the one before?

I guess this is going too far, as Babel is untyped: what about...

    #+property: var   foo=2
    #+property: var+  5

Does foo become equal to 25?

(I know I exaggerate somehow, but just to show I guess such extensions are
simply not possible without explicit types).

But, if not equal to 25, what would be expected?  An error, ...?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2025 bytes --]

On Tue, Nov 8, 2011 at 10:58 AM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Rainer,
>
> Rainer M Krug wrote:
> >> > * appending to a file-wide property
> >> >   :PROPERTIES:
> >> >   :var+:      , baz=3
> >> >   :END:
> >>
> >> To be honest, the only thing that I dislike is the comma in the above
> line.
> >> Not intuitive at all. Quite hard to read.
> >>
> >> Can't the comma be implicitly added by the `+' after the property name?
> >
> > On the one hand, it might have one additional advantage:
> >
> >   #+property: var   foo="This is a very long text"
> >   #+property: var+ "with even more."
>
> I don't think such a construction would be tolerated. I guess you must
> write
> a var name (foo, bar, baz, ...) after the `var+' keyword.
>
> > Would foo be:
> > "This is a very long text with even more"
>
> To be accurate, it would have become:
>
>  "This is a very long textwith even more"
>
> if such a concatenation would be implied.
>

Correct - missing space.


>
> > Could one make the "," implicit, if the value follows the
> >
> > x=y
> >
> > style, while otherwise just concatenate the value to the one before?
>
> I guess this is going too far, as Babel is untyped: what about...
>
>    #+property: var   foo=2
>    #+property: var+  5
>
> Does foo become equal to 25?
>
> (I know I exaggerate somehow, but just to show I guess such extensions are
> simply not possible without explicit types).
>
>
You definitely have a point here - so I opt for the implicit ","


Cheers,

Rainer

But, if not equal to 25, what would be expected?  An error, ...?
>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 3229 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Darlan Cavalcante Moreira]

Unless I have missed something in the e-mails, the new syntax is to
concatenate new variables to the var property. Not modifying the values
currently stored in some variable. That is,
  #+property: var   foo=2
  #+property: var+  5
(not specifying the variable name ) should not be allowed and
  #+property: var   foo=2
  #+property: var+  foo=5
  #+property: var+  bar="bar"
should result in foo=5 and bar="bar". Is modifying a variable also a new
feature?

--
Darlan

At Tue, 8 Nov 2011 11:06:48 +0100,
Rainer M Krug <r.m.krug@gmail.com> wrote:
> 
> [1  <text/plain; ISO-8859-1 (7bit)>]
> On Tue, Nov 8, 2011 at 10:58 AM, Sebastien Vauban <
> wxhgmqzgwmuf@spammotel.com> wrote:
> 
> > Hi Rainer,
> >
> > Rainer M Krug wrote:
> > >> > * appending to a file-wide property
> > >> >   :PROPERTIES:
> > >> >   :var+:      , baz=3
> > >> >   :END:
> > >>
> > >> To be honest, the only thing that I dislike is the comma in the above
> > line.
> > >> Not intuitive at all. Quite hard to read.
> > >>
> > >> Can't the comma be implicitly added by the `+' after the property name?
> > >
> > > On the one hand, it might have one additional advantage:
> > >
> > >   #+property: var   foo="This is a very long text"
> > >   #+property: var+ "with even more."
> >
> > I don't think such a construction would be tolerated. I guess you must
> > write
> > a var name (foo, bar, baz, ...) after the `var+' keyword.
> >
> > > Would foo be:
> > > "This is a very long text with even more"
> >
> > To be accurate, it would have become:
> >
> >  "This is a very long textwith even more"
> >
> > if such a concatenation would be implied.
> >
> 
> Correct - missing space.
> 
> 
> >
> > > Could one make the "," implicit, if the value follows the
> > >
> > > x=y
> > >
> > > style, while otherwise just concatenate the value to the one before?
> >
> > I guess this is going too far, as Babel is untyped: what about...
> >
> >    #+property: var   foo=2
> >    #+property: var+  5
> >
> > Does foo become equal to 25?
> >
> > (I know I exaggerate somehow, but just to show I guess such extensions are
> > simply not possible without explicit types).
> >
> >
> You definitely have a point here - so I opt for the implicit ","
> 
> 
> Cheers,
> 
> Rainer
> 
> But, if not equal to 25, what would be expected?  An error, ...?
> >
> > Best regards,
> >  Seb
> >
> > --
> > Sebastien Vauban
> >
> >
> >
> 
> 
> -- 
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
> UCT), Dipl. Phys. (Germany)
> 
> Centre of Excellence for Invasion Biology
> Stellenbosch University
> South Africa
> 
> Tel :       +33 - (0)9 53 10 27 44
> Cell:       +33 - (0)6 85 62 59 98
> Fax (F):       +33 - (0)9 58 10 27 44
> 
> Fax (D):    +49 - (0)3 21 21 25 22 44
> 
> email:      Rainer@krugs.de
> 
> Skype:      RMkrug
> [2  <text/html; ISO-8859-1 (quoted-printable)>]
> 

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Sebastien Vauban]

Hi Darlan,

Darlan Cavalcante Moreira wrote:
> Unless I have missed something in the e-mails, the new syntax is to
> concatenate new variables to the var property. Not modifying the values
> currently stored in some variable. That is,
>   #+property: var   foo=2
>   #+property: var+  5
> (not specifying the variable name ) should not be allowed

By showing this example, I wanted to show that this proposition (of Rainer)
seemed wrong to me. This is much too complex, and I think there is no use case
to support such a thing.

> and
>   #+property: var   foo=2
>   #+property: var+  foo=5
>   #+property: var+  bar="bar"
> should result in foo=5 and bar="bar".

Yep -- iff the comma is implied (implicitly), what's not currently the case.

> Is modifying a variable also a new feature?

Not (to me).

Best regards,
  Seb

-- 
Sebastien Vauban

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

>>
>> > Could one make the "," implicit, if the value follows the
>> >
>> > x=y
>> >
>> > style, while otherwise just concatenate the value to the one before?
>>
>> I guess this is going too far, as Babel is untyped: what about...
>>
>>    #+property: var   foo=2
>>    #+property: var+  5
>>
>> Does foo become equal to 25?
>>

yes

#+PROPERTY: var foo=2
#+PROPERTY: var+ 5

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 25

>>
>> (I know I exaggerate somehow, but just to show I guess such
>>  extensions are simply not possible without explicit types).
>>

I think by types you mean something more like syntactic parsing?  Babel
does have three types, strings, numbers, and lists.

>>
>>
> You definitely have a point here - so I opt for the implicit ","
>

Keep in mind that the above applies to *all* Org-mode properties, not
just variables, which is why I did not want to force an assumed comma
separator.

For example,

#+PROPERTY: Disks  1 2 3 4 5 6 7
#+PROPERTY: Disks+ 8 9 10 11 12 13

#+begin_src emacs-lisp
  org-file-properties
#+end_src

#+results:
| (var . foo=25) | (Disks . 1 2 3 4 5 6 78 9 10 11 12 13) |

Although in this case the 78 is certainly unexpected.  Perhaps inserting
an assumed space separator would be more intuitive?  If we were to go
that way it may be possible to allow variable specifications such as

#+PROPERTY: var foo=1 bar=2

in which case properties could be easily specified on multiple lines
using a default space separator.

If this seems like a good way to go I can try to update my previous
patch.

Thanks -- Eric

>
>
> Cheers,
>
> Rainer
>
> But, if not equal to 25, what would be expected?  An error, ...?
>>
>> Best regards,
>>  Seb
>>
>> --
>> Sebastien Vauban
>>
>>
>>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

> Perhaps inserting an assumed space separator would be more intuitive?
> If we were to go that way it may be possible to allow variable
> specifications such as
>
> #+PROPERTY: var foo=1 bar=2
>
> in which case properties could be easily specified on multiple lines
> using a default space separator.
>
> If this seems like a good way to go I can try to update my previous
> patch.
>

I've updated the patch, the newest version is attached.  It results in
the following behavior.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: something.org --]
[-- Type: text/x-org, Size: 674 bytes --]

#+property: var  foo=1
#+property: var+ bar=2

#+begin_src emacs-lisp
  (+ foo bar)
#+end_src

#+results:
: 3

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1 bar=2

* overwriting a file-wide property
  :PROPERTIES:
  :var:      foo=7
  :END:

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 7

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=7

* appending to a file-wide property
  :PROPERTIES:
  :var+:      baz=3
  :END:

#+begin_src emacs-lisp
  (+ foo bar baz)
#+end_src

#+results:
: 6

#+begin_src emacs-lisp
  (org-entry-get (point) "var" t)
#+end_src

#+results:
: foo=1 bar=2 baz=3

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0001-property-names-ending-in-plus-accumulate.patch --]
[-- Type: text/x-diff, Size: 9865 bytes --]

From 2a4bc429a38470b71baabf73d160359f8f87c9de Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Mon, 7 Nov 2011 14:49:42 -0700
Subject: [PATCH] property names ending in plus accumulate

This results in the following behavior.

  #+property: var  foo=1
  #+property: var+ bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1 bar=2

  * overwriting a file-wide property
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=7

  * appending to a file-wide property
    :PROPERTIES:
    :var+:      baz=3
    :END:

  #+begin_src emacs-lisp
    (+ foo bar baz)
  #+end_src

  #+results:
  : 6

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1 bar=2 baz=3

* lisp/org.el (org-update-property-plist): Updates a given property
  list with a property name and a property value.
  (org-set-regexps-and-options): Use org-update-property-plist.
  (org-entry-get): Use org-update-property-plist.
* testing/examples/property-inheritance.org: Example file for testing
  appending property behavior.
* testing/lisp/test-property-inheritance.el: Tests of appending
  property behavior.
* lisp/ob.el (org-babel-balanced-split): Allow splitting on single
  characters as well as groups of two characters.
  (org-babel-parse-multiple-vars): Split variables on single spaces.
---
 lisp/ob.el                                |   13 ++++--
 lisp/org.el                               |   47 +++++++++++++++-------
 testing/examples/property-inheritance.org |   36 +++++++++++++++++
 testing/lisp/test-property-inheritance.el |   61 +++++++++++++++++++++++++++++
 4 files changed, 138 insertions(+), 19 deletions(-)
 create mode 100644 testing/examples/property-inheritance.org
 create mode 100644 testing/lisp/test-property-inheritance.el

diff --git a/lisp/ob.el b/lisp/ob.el
index d94b4b6..a1526bc 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1118,8 +1118,10 @@ instances of \"[ \t]:\" set ALTS to '((32 9) . 58)."
   (flet ((matches (ch spec) (or (and (numberp spec) (= spec ch))
 				(member ch spec)))
 	 (matched (ch last)
-		  (and (matches ch (cdr alts))
-		       (matches last (car alts)))))
+		  (if (consp alts)
+		      (and (matches ch (cdr alts))
+			   (matches last (car alts)))
+		    (matches ch alts))))
     (let ((balance 0) (partial nil) (lst nil) (last 0))
       (mapc (lambda (ch)  ; split on [] or () balanced instances of [ \t]:
 	      (setq balance (+ balance
@@ -1128,7 +1130,10 @@ instances of \"[ \t]:\" set ALTS to '((32 9) . 58)."
 				     (t 0))))
 	      (setq partial (cons ch partial))
 	      (when (and (= balance 0) (matched ch last))
-		(setq lst (cons (apply #'string (nreverse (cddr partial)))
+		(setq lst (cons (apply #'string (nreverse
+						 (if (consp alts)
+						     (cddr partial)
+						   (cdr partial))))
 				lst))
 		(setq partial nil))
 	      (setq last ch))
@@ -1163,7 +1168,7 @@ shown below.
     (mapc (lambda (pair)
 	    (if (eq (car pair) :var)
 		(mapcar (lambda (v) (push (cons :var (org-babel-trim v)) results))
-			(org-babel-balanced-split (cdr pair) '(44 . (32 9))))
+			(org-babel-balanced-split (cdr pair) 32))
 	      (push pair results)))
 	  header-arguments)
     (nreverse results)))
diff --git a/lisp/org.el b/lisp/org.el
index 5c4ea33..d74e994 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4438,6 +4438,15 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.")
 
+(defun org-update-property-plist (key val props)
+  "Update PROPS with KEY and VAL."
+  (if (string= "+" (substring key (- (length key) 1)))
+      (let* ((key (substring key 0 (- (length key) 1)))
+	     (previous (cdr (assoc key props))))
+	(cons (cons key (concat previous " " val))
+	      (org-remove-if (lambda (p) (string= (car p) key)) props)))
+    (cons (cons key val) props)))
+
 (defun org-set-regexps-and-options ()
   "Precompute regular expressions for current buffer."
   (when (eq major-mode 'org-mode)
@@ -4499,8 +4508,9 @@ means to push this value onto the list in the variable.")
 	      (setq prio (org-split-string value " +")))
 	     ((equal key "PROPERTY")
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props)))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props))))
 	     ((equal key "FILETAGS")
 	      (when (string-match "\\S-" value)
 		(setq ftags
@@ -4552,8 +4562,9 @@ means to push this value onto the list in the variable.")
 	      (setq value (replace-regexp-in-string
 			   "[\n\r]" " " (match-string 4)))
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props))))))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props)))))))
       (org-set-local 'org-use-sub-superscripts scripts)
       (when cat
 	(org-set-local 'org-category (intern cat))
@@ -14083,17 +14094,23 @@ when a \"nil\" value can supersede a non-nil value higher up the hierarchy."
 	  (cdr (assoc property (org-entry-properties nil 'special property)))
 	(let ((range (unless (org-before-first-heading-p)
 		       (org-get-property-block))))
-	  (if (and range
-		   (goto-char (car range))
-		   (re-search-forward
-		    (org-re-property property)
-		    (cdr range) t))
-	      ;; Found the property, return it.
-	      (if (match-end 1)
-		  (if literal-nil
-		      (org-match-string-no-properties 1)
-		    (org-not-nil (org-match-string-no-properties 1)))
-		"")))))))
+	  (when (and range (goto-char (car range)))
+	    ((lambda (val) (when val (if literal-nil val (org-not-nil val))))
+	     (cond
+	      ((re-search-forward
+		(org-re-property property) (cdr range) t)
+	       (if (match-end 1) (org-match-string-no-properties 1) ""))
+	      ((re-search-forward
+		(org-re-property (concat property "+")) (cdr range) t)
+	       (cdr (assoc
+		     property
+		     (org-update-property-plist
+		      (concat property "+")
+		      (if (match-end 1) (org-match-string-no-properties 1) "")
+		      (list (or (assoc property org-file-properties)
+				(assoc property org-global-properties)
+				(assoc property org-global-properties-fixed)
+				))))))))))))))
 
 (defun org-property-or-variable-value (var &optional inherit)
   "Check if there is a property fixing the value of VAR.
diff --git a/testing/examples/property-inheritance.org b/testing/examples/property-inheritance.org
new file mode 100644
index 0000000..de5b539
--- /dev/null
+++ b/testing/examples/property-inheritance.org
@@ -0,0 +1,36 @@
+#+property: var  foo=1
+#+property: var+ bar=2
+
+#+begin_src emacs-lisp
+  (+ foo bar)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* overwriting a file-wide property
+  :PROPERTIES:
+  :var:      foo=7
+  :END:
+
+#+begin_src emacs-lisp
+  foo
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* appending to a file-wide property
+  :PROPERTIES:
+  :var+:      baz=3
+  :END:
+
+#+begin_src emacs-lisp
+  (+ foo bar baz)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
diff --git a/testing/lisp/test-property-inheritance.el b/testing/lisp/test-property-inheritance.el
new file mode 100644
index 0000000..60e955d
--- /dev/null
+++ b/testing/lisp/test-property-inheritance.el
@@ -0,0 +1,61 @@
+;;; test-ob-R.el --- tests for ob-R.el
+
+;; Copyright (c) 2011 Eric Schulte
+;; Authors: Eric Schulte
+
+;; Released under the GNU General Public License version 3
+;; see: http://www.gnu.org/licenses/gpl-3.0.html
+
+(let ((load-path (cons (expand-file-name
+			".." (file-name-directory
+			      (or load-file-name buffer-file-name)))
+		       load-path)))
+  (require 'org-test)
+  (require 'org-test-ob-consts))
+
+(defmacro test-org-in-property-buffer (&rest body)
+  `(with-temp-buffer
+     (insert-file-contents (expand-file-name "property-inheritance.org"
+					     org-test-example-dir))
+     (org-mode)
+     ,@body))
+
+(ert-deftest test-org-property-accumulation-top-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 1)
+   (should (equal 3 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-top-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 2)
+   (should (string= "foo=1 bar=2" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 3)
+   (should (= 7 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 4)
+   (should (string= "foo=7" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 5)
+   (should (= 6 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 6)
+   (should (string= "foo=1 bar=2 baz=3" (org-babel-execute-src-block)))))
+
+(provide 'test-ob-R)
+
+;;; test-ob-R.el ends here
-- 
1.7.4.1


[-- Attachment #4: Type: text/plain, Size: 47 bytes --]


-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> > Perhaps inserting an assumed space separator would be more intuitive?
> > If we were to go that way it may be possible to allow variable
> > specifications such as
> >
> > #+PROPERTY: var foo=1 bar=2
> >
> > in which case properties could be easily specified on multiple lines
> > using a default space separator.
> >
> > If this seems like a good way to go I can try to update my previous
> > patch.
> >
>
> I've updated the patch, the newest version is attached.  It results in
> the following behavior.
>

Looks good to me - that leaves just the question, what would hppen when
doing the following:

#+property: var  foo=1
#+property: var+ 2

and

#+property: var  foo="Hello "
#+property: var+ "world"

Thanks,

Rainer


>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 1861 bytes --]

Rainer M Krug <r.m.krug@gmail.com> writes:

> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com>wrote:
>
>> > Perhaps inserting an assumed space separator would be more intuitive?
>> > If we were to go that way it may be possible to allow variable
>> > specifications such as
>> >
>> > #+PROPERTY: var foo=1 bar=2
>> >
>> > in which case properties could be easily specified on multiple lines
>> > using a default space separator.
>> >
>> > If this seems like a good way to go I can try to update my previous
>> > patch.
>> >
>>
>> I've updated the patch, the newest version is attached.  It results in
>> the following behavior.
>>
>
> Looks good to me - that leaves just the question, what would hppen when
> doing the following:
>
> #+property: var  foo=1
> #+property: var+ 2
>

The above is equivalent to,

#+header: :var foo=1 2

which due to interaction with some logic put in place to allow the
specification of un-named variables in call lines results in the
following.

#+property: var  foo=1
#+property: var+ 2

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: 2

#+begin_src emacs-lisp :var bar=1 2
  bar  
#+end_src

#+results:
: 2

Although generally I would say that both

#+header: :var foo=1 2

and 

#+property: var  foo=1
#+property: var+ 2

are mal-formed variable assignments.

>
> and
>
> #+property: var  foo="Hello "
> #+property: var+ "world"
>

This is exactly analogous to

#+header: :var foo="hello" "world"

which raises the expected error
  ``variable ""world"" must be assigned a default value''

the following alternative however works as expected

#+property: var  foo="Hello
#+property: var+ world"

#+begin_src emacs-lisp
  foo
#+end_src

#+results:
: Hello world

Thanks for these examples, the later did brought to light a small
quoting issue which is fixed in the new attached patch.

Best -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-property-names-ending-in-plus-accumulate.patch --]
[-- Type: text/x-diff, Size: 10192 bytes --]

From 3be23a3631d108e19d2b8d781077130f1e12bb19 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Mon, 7 Nov 2011 14:49:42 -0700
Subject: [PATCH] property names ending in plus accumulate

This results in the following behavior.

  #+property: var  foo=1
  #+property: var+ bar=2

  #+begin_src emacs-lisp
    (+ foo bar)
  #+end_src

  #+results:
  : 3

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1 bar=2

  * overwriting a file-wide property
    :PROPERTIES:
    :var:      foo=7
    :END:

  #+begin_src emacs-lisp
    foo
  #+end_src

  #+results:
  : 7

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=7

  * appending to a file-wide property
    :PROPERTIES:
    :var+:      baz=3
    :END:

  #+begin_src emacs-lisp
    (+ foo bar baz)
  #+end_src

  #+results:
  : 6

  #+begin_src emacs-lisp
    (org-entry-get (point) "var" t)
  #+end_src

  #+results:
  : foo=1 bar=2 baz=3

* lisp/org.el (org-update-property-plist): Updates a given property
  list with a property name and a property value.
  (org-set-regexps-and-options): Use org-update-property-plist.
  (org-entry-get): Use org-update-property-plist.
* testing/examples/property-inheritance.org: Example file for testing
  appending property behavior.
* testing/lisp/test-property-inheritance.el: Tests of appending
  property behavior.
* lisp/ob.el (org-babel-balanced-split): Allow splitting on single
  characters as well as groups of two characters.
  (org-babel-parse-multiple-vars): Split variables on single spaces.
---
 lisp/ob.el                                |   21 +++++++---
 lisp/org.el                               |   47 +++++++++++++++-------
 testing/examples/property-inheritance.org |   36 +++++++++++++++++
 testing/lisp/test-property-inheritance.el |   61 +++++++++++++++++++++++++++++
 4 files changed, 143 insertions(+), 22 deletions(-)
 create mode 100644 testing/examples/property-inheritance.org
 create mode 100644 testing/lisp/test-property-inheritance.el

diff --git a/lisp/ob.el b/lisp/ob.el
index d94b4b6..51ae9c4 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -1118,17 +1118,24 @@ instances of \"[ \t]:\" set ALTS to '((32 9) . 58)."
   (flet ((matches (ch spec) (or (and (numberp spec) (= spec ch))
 				(member ch spec)))
 	 (matched (ch last)
-		  (and (matches ch (cdr alts))
-		       (matches last (car alts)))))
-    (let ((balance 0) (partial nil) (lst nil) (last 0))
-      (mapc (lambda (ch)  ; split on [] or () balanced instances of [ \t]:
+		  (if (consp alts)
+		      (and (matches ch (cdr alts))
+			   (matches last (car alts)))
+		    (matches ch alts))))
+    (let ((balance 0) (quote nil) (partial nil) (lst nil) (last 0))
+      (mapc (lambda (ch)  ; split on [], (), "" balanced instances of [ \t]:
 	      (setq balance (+ balance
 			       (cond ((or (equal 91 ch) (equal 40 ch)) 1)
 				     ((or (equal 93 ch) (equal 41 ch)) -1)
 				     (t 0))))
+	      (when (and (equal 34 ch) (not (equal 92 last)))
+		(setq quote (not quote)))
 	      (setq partial (cons ch partial))
-	      (when (and (= balance 0) (matched ch last))
-		(setq lst (cons (apply #'string (nreverse (cddr partial)))
+	      (when (and (= balance 0) (not quote) (matched ch last))
+		(setq lst (cons (apply #'string (nreverse
+						 (if (consp alts)
+						     (cddr partial)
+						   (cdr partial))))
 				lst))
 		(setq partial nil))
 	      (setq last ch))
@@ -1163,7 +1170,7 @@ shown below.
     (mapc (lambda (pair)
 	    (if (eq (car pair) :var)
 		(mapcar (lambda (v) (push (cons :var (org-babel-trim v)) results))
-			(org-babel-balanced-split (cdr pair) '(44 . (32 9))))
+			(org-babel-balanced-split (cdr pair) 32))
 	      (push pair results)))
 	  header-arguments)
     (nreverse results)))
diff --git a/lisp/org.el b/lisp/org.el
index 5c4ea33..d74e994 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -4438,6 +4438,15 @@ in the #+STARTUP line, the corresponding variable, and the value to
 set this variable to if the option is found.  An optional forth element PUSH
 means to push this value onto the list in the variable.")
 
+(defun org-update-property-plist (key val props)
+  "Update PROPS with KEY and VAL."
+  (if (string= "+" (substring key (- (length key) 1)))
+      (let* ((key (substring key 0 (- (length key) 1)))
+	     (previous (cdr (assoc key props))))
+	(cons (cons key (concat previous " " val))
+	      (org-remove-if (lambda (p) (string= (car p) key)) props)))
+    (cons (cons key val) props)))
+
 (defun org-set-regexps-and-options ()
   "Precompute regular expressions for current buffer."
   (when (eq major-mode 'org-mode)
@@ -4499,8 +4508,9 @@ means to push this value onto the list in the variable.")
 	      (setq prio (org-split-string value " +")))
 	     ((equal key "PROPERTY")
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props)))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props))))
 	     ((equal key "FILETAGS")
 	      (when (string-match "\\S-" value)
 		(setq ftags
@@ -4552,8 +4562,9 @@ means to push this value onto the list in the variable.")
 	      (setq value (replace-regexp-in-string
 			   "[\n\r]" " " (match-string 4)))
 	      (when (string-match "\\(\\S-+\\)\\s-+\\(.*\\)" value)
-		(push (cons (match-string 1 value) (match-string 2 value))
-		      props))))))
+		(setq props (org-update-property-plist (match-string 1 value)
+						       (match-string 2 value)
+						       props)))))))
       (org-set-local 'org-use-sub-superscripts scripts)
       (when cat
 	(org-set-local 'org-category (intern cat))
@@ -14083,17 +14094,23 @@ when a \"nil\" value can supersede a non-nil value higher up the hierarchy."
 	  (cdr (assoc property (org-entry-properties nil 'special property)))
 	(let ((range (unless (org-before-first-heading-p)
 		       (org-get-property-block))))
-	  (if (and range
-		   (goto-char (car range))
-		   (re-search-forward
-		    (org-re-property property)
-		    (cdr range) t))
-	      ;; Found the property, return it.
-	      (if (match-end 1)
-		  (if literal-nil
-		      (org-match-string-no-properties 1)
-		    (org-not-nil (org-match-string-no-properties 1)))
-		"")))))))
+	  (when (and range (goto-char (car range)))
+	    ((lambda (val) (when val (if literal-nil val (org-not-nil val))))
+	     (cond
+	      ((re-search-forward
+		(org-re-property property) (cdr range) t)
+	       (if (match-end 1) (org-match-string-no-properties 1) ""))
+	      ((re-search-forward
+		(org-re-property (concat property "+")) (cdr range) t)
+	       (cdr (assoc
+		     property
+		     (org-update-property-plist
+		      (concat property "+")
+		      (if (match-end 1) (org-match-string-no-properties 1) "")
+		      (list (or (assoc property org-file-properties)
+				(assoc property org-global-properties)
+				(assoc property org-global-properties-fixed)
+				))))))))))))))
 
 (defun org-property-or-variable-value (var &optional inherit)
   "Check if there is a property fixing the value of VAR.
diff --git a/testing/examples/property-inheritance.org b/testing/examples/property-inheritance.org
new file mode 100644
index 0000000..de5b539
--- /dev/null
+++ b/testing/examples/property-inheritance.org
@@ -0,0 +1,36 @@
+#+property: var  foo=1
+#+property: var+ bar=2
+
+#+begin_src emacs-lisp
+  (+ foo bar)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* overwriting a file-wide property
+  :PROPERTIES:
+  :var:      foo=7
+  :END:
+
+#+begin_src emacs-lisp
+  foo
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
+
+* appending to a file-wide property
+  :PROPERTIES:
+  :var+:      baz=3
+  :END:
+
+#+begin_src emacs-lisp
+  (+ foo bar baz)
+#+end_src
+
+#+begin_src emacs-lisp
+  (org-entry-get (point) "var" t)
+#+end_src
diff --git a/testing/lisp/test-property-inheritance.el b/testing/lisp/test-property-inheritance.el
new file mode 100644
index 0000000..60e955d
--- /dev/null
+++ b/testing/lisp/test-property-inheritance.el
@@ -0,0 +1,61 @@
+;;; test-ob-R.el --- tests for ob-R.el
+
+;; Copyright (c) 2011 Eric Schulte
+;; Authors: Eric Schulte
+
+;; Released under the GNU General Public License version 3
+;; see: http://www.gnu.org/licenses/gpl-3.0.html
+
+(let ((load-path (cons (expand-file-name
+			".." (file-name-directory
+			      (or load-file-name buffer-file-name)))
+		       load-path)))
+  (require 'org-test)
+  (require 'org-test-ob-consts))
+
+(defmacro test-org-in-property-buffer (&rest body)
+  `(with-temp-buffer
+     (insert-file-contents (expand-file-name "property-inheritance.org"
+					     org-test-example-dir))
+     (org-mode)
+     ,@body))
+
+(ert-deftest test-org-property-accumulation-top-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 1)
+   (should (equal 3 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-top-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 2)
+   (should (string= "foo=1 bar=2" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 3)
+   (should (= 7 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-overwrite-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 4)
+   (should (string= "foo=7" (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-use ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 5)
+   (should (= 6 (org-babel-execute-src-block)))))
+
+(ert-deftest test-org-property-accumulation-append-val ()
+  (test-org-in-property-buffer
+   (goto-char (point-min))
+   (org-babel-next-src-block 6)
+   (should (string= "foo=1 bar=2 baz=3" (org-babel-execute-src-block)))))
+
+(provide 'test-ob-R)
+
+;;; test-ob-R.el ends here
-- 
1.7.4.1


[-- Attachment #3: Type: text/plain, Size: 141 bytes --]


>
> Thanks,
>
> Rainer
>
>
>>
>>
>> --
>> Eric Schulte
>> http://cs.unm.edu/~eschulte/
>>
>>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 2780 bytes --]

On Wed, Nov 9, 2011 at 5:12 PM, Eric Schulte <schulte.eric@gmail.com> wrote:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com
> >wrote:
> >
> >> > Perhaps inserting an assumed space separator would be more intuitive?
> >> > If we were to go that way it may be possible to allow variable
> >> > specifications such as
> >> >
> >> > #+PROPERTY: var foo=1 bar=2
> >> >
> >> > in which case properties could be easily specified on multiple lines
> >> > using a default space separator.
> >> >
> >> > If this seems like a good way to go I can try to update my previous
> >> > patch.
> >> >
> >>
> >> I've updated the patch, the newest version is attached.  It results in
> >> the following behavior.
> >>
> >
> > Looks good to me - that leaves just the question, what would hppen when
> > doing the following:
> >
> > #+property: var  foo=1
> > #+property: var+ 2
> >
>
> The above is equivalent to,
>
> #+header: :var foo=1 2
>
> which due to interaction with some logic put in place to allow the
> specification of un-named variables in call lines results in the
> following.
>
> #+property: var  foo=1
> #+property: var+ 2
>
> #+begin_src emacs-lisp
>  foo
> #+end_src
>
> #+results:
> : 2
>
> #+begin_src emacs-lisp :var bar=1 2
>  bar
> #+end_src
>
> #+results:
> : 2
>
> Although generally I would say that both
>
> #+header: :var foo=1 2
>
> and
>
> #+property: var  foo=1
> #+property: var+ 2
>
> are mal-formed variable assignments.
>

True.


>
> >
> > and
> >
> > #+property: var  foo="Hello "
> > #+property: var+ "world"
> >
>
> This is exactly analogous to
>
> #+header: :var foo="hello" "world"
>

Makes sense


>
> which raises the expected error
>  ``variable ""world"" must be assigned a default value''
>
> the following alternative however works as expected
>
> #+property: var  foo="Hello
> #+property: var+ world"
>
> #+begin_src emacs-lisp
>  foo
> #+end_src
>
> #+results:
> : Hello world
>

Lovely - so I can break longer string characters in multiple lines -
brilliant.


>
> Thanks for these examples, the later did brought to light a small
> quoting issue which is fixed in the new attached patch.
>
> Best -- Eric
>
>
>
> >
> > Thanks,
> >
> > Rainer
> >
> >
> >>
> >>
> >> --
> >> Eric Schulte
> >> http://cs.unm.edu/~eschulte/
> >>
> >>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 4689 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Sebastien Vauban]

Hi Eric,

Eric Schulte wrote:
> Rainer M Krug <r.m.krug-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>wrote:
>>
>>> > Perhaps inserting an assumed space separator would be more intuitive?
>>> > If we were to go that way it may be possible to allow variable
>>> > specifications such as
>>> >
>>> > #+PROPERTY: var foo=1 bar=2
>>> >
>>> > in which case properties could be easily specified on multiple lines
>>> > using a default space separator.
>>> >
>>> > If this seems like a good way to go I can try to update my previous
>>> > patch.
>>>
>>> I've updated the patch, the newest version is attached.  It results in
>>> the following behavior.
>>
>> Looks good to me - that leaves just the question, what would hppen when
>> doing the following:
>>
>> #+property: var  foo=1
>> #+property: var+ 2
>
> The above is equivalent to,
>
> #+header: :var foo=1 2
>
> which due to interaction with some logic put in place to allow the
> specification of un-named variables in call lines results in the
> following.
>
> #+property: var  foo=1
> #+property: var+ 2
> #+begin_src emacs-lisp
>   foo
> #+end_src
>
> #+results:
> : 2
>
> #+begin_src emacs-lisp :var bar=1 2
>   bar  
> #+end_src
>
> #+results:
> : 2
>
> Although generally I would say that both
>
> #+header: :var foo=1 2
>
> and 
>
> #+property: var  foo=1
> #+property: var+ 2
>
> are mal-formed variable assignments.

I was amazed, yesterday, when you told about `foo' becoming `12' (with `1' on
the assignment line and `2' on the continuation), but I'm glad you consider
this as rather ill-formed.

>> and
>>
>> #+property: var  foo="Hello "
>> #+property: var+ "world"
>
> This is exactly analogous to
>
> #+header: :var foo="hello" "world"
>
> which raises the expected error
>   ``variable ""world"" must be assigned a default value''
>
> the following alternative however works as expected
>
> #+property: var  foo="Hello
> #+property: var+ world"
> #+begin_src emacs-lisp
>   foo
> #+end_src
>
> #+results:
> : Hello world

That said, all of these seem excellent trade-off between the different
alternatives that have been discussed and analyzed, and they respect important
aspects: simplicity (intuitive on reading) and powerfulness.

Just perfect!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

Is that patch on git yet? i.e. if can I switch back to HEAD and change my
files accordingly?

Cheers,

Rainer


On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Eric,
>
> Eric Schulte wrote:
> > Rainer M Krug <r.m.krug@gmail.com> writes:
> >
> >> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com
> >wrote:
> >>
> >>> > Perhaps inserting an assumed space separator would be more intuitive?
> >>> > If we were to go that way it may be possible to allow variable
> >>> > specifications such as
> >>> >
> >>> > #+PROPERTY: var foo=1 bar=2
> >>> >
> >>> > in which case properties could be easily specified on multiple lines
> >>> > using a default space separator.
> >>> >
> >>> > If this seems like a good way to go I can try to update my previous
> >>> > patch.
> >>>
> >>> I've updated the patch, the newest version is attached.  It results in
> >>> the following behavior.
> >>
> >> Looks good to me - that leaves just the question, what would hppen when
> >> doing the following:
> >>
> >> #+property: var  foo=1
> >> #+property: var+ 2
> >
> > The above is equivalent to,
> >
> > #+header: :var foo=1 2
> >
> > which due to interaction with some logic put in place to allow the
> > specification of un-named variables in call lines results in the
> > following.
> >
> > #+property: var  foo=1
> > #+property: var+ 2
> > #+begin_src emacs-lisp
> >   foo
> > #+end_src
> >
> > #+results:
> > : 2
> >
> > #+begin_src emacs-lisp :var bar=1 2
> >   bar
> > #+end_src
> >
> > #+results:
> > : 2
> >
> > Although generally I would say that both
> >
> > #+header: :var foo=1 2
> >
> > and
> >
> > #+property: var  foo=1
> > #+property: var+ 2
> >
> > are mal-formed variable assignments.
>
> I was amazed, yesterday, when you told about `foo' becoming `12' (with `1'
> on
> the assignment line and `2' on the continuation), but I'm glad you consider
> this as rather ill-formed.
>
> >> and
> >>
> >> #+property: var  foo="Hello "
> >> #+property: var+ "world"
> >
> > This is exactly analogous to
> >
> > #+header: :var foo="hello" "world"
> >
> > which raises the expected error
> >   ``variable ""world"" must be assigned a default value''
> >
> > the following alternative however works as expected
> >
> > #+property: var  foo="Hello
> > #+property: var+ world"
> > #+begin_src emacs-lisp
> >   foo
> > #+end_src
> >
> > #+results:
> > : Hello world
>
> That said, all of these seem excellent trade-off between the different
> alternatives that have been discussed and analyzed, and they respect
> important
> aspects: simplicity (intuitive on reading) and powerfulness.
>
> Just perfect!
>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 4484 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Rainer M Krug <r.m.krug@gmail.com> writes:

> Is that patch on git yet? i.e. if can I switch back to HEAD and change my
> files accordingly?
>

Hi Rainer,

I've must merged all of the pending code block changes into the master
branch of the Org-mode git repository.  So now would be a good time to
re-sync with the master branch.

Best -- Eric

>
> Cheers,
>
> Rainer
>
>
> On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban <
> wxhgmqzgwmuf@spammotel.com> wrote:
>
>> Hi Eric,
>>
>> Eric Schulte wrote:
>> > Rainer M Krug <r.m.krug@gmail.com> writes:
>> >
>> >> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <schulte.eric@gmail.com
>> >wrote:
>> >>
>> >>> > Perhaps inserting an assumed space separator would be more intuitive?
>> >>> > If we were to go that way it may be possible to allow variable
>> >>> > specifications such as
>> >>> >
>> >>> > #+PROPERTY: var foo=1 bar=2
>> >>> >
>> >>> > in which case properties could be easily specified on multiple lines
>> >>> > using a default space separator.
>> >>> >
>> >>> > If this seems like a good way to go I can try to update my previous
>> >>> > patch.
>> >>>
>> >>> I've updated the patch, the newest version is attached.  It results in
>> >>> the following behavior.
>> >>
>> >> Looks good to me - that leaves just the question, what would hppen when
>> >> doing the following:
>> >>
>> >> #+property: var  foo=1
>> >> #+property: var+ 2
>> >
>> > The above is equivalent to,
>> >
>> > #+header: :var foo=1 2
>> >
>> > which due to interaction with some logic put in place to allow the
>> > specification of un-named variables in call lines results in the
>> > following.
>> >
>> > #+property: var  foo=1
>> > #+property: var+ 2
>> > #+begin_src emacs-lisp
>> >   foo
>> > #+end_src
>> >
>> > #+results:
>> > : 2
>> >
>> > #+begin_src emacs-lisp :var bar=1 2
>> >   bar
>> > #+end_src
>> >
>> > #+results:
>> > : 2
>> >
>> > Although generally I would say that both
>> >
>> > #+header: :var foo=1 2
>> >
>> > and
>> >
>> > #+property: var  foo=1
>> > #+property: var+ 2
>> >
>> > are mal-formed variable assignments.
>>
>> I was amazed, yesterday, when you told about `foo' becoming `12' (with `1'
>> on
>> the assignment line and `2' on the continuation), but I'm glad you consider
>> this as rather ill-formed.
>>
>> >> and
>> >>
>> >> #+property: var  foo="Hello "
>> >> #+property: var+ "world"
>> >
>> > This is exactly analogous to
>> >
>> > #+header: :var foo="hello" "world"
>> >
>> > which raises the expected error
>> >   ``variable ""world"" must be assigned a default value''
>> >
>> > the following alternative however works as expected
>> >
>> > #+property: var  foo="Hello
>> > #+property: var+ world"
>> > #+begin_src emacs-lisp
>> >   foo
>> > #+end_src
>> >
>> > #+results:
>> > : Hello world
>>
>> That said, all of these seem excellent trade-off between the different
>> alternatives that have been discussed and analyzed, and they respect
>> important
>> aspects: simplicity (intuitive on reading) and powerfulness.
>>
>> Just perfect!
>>
>> Best regards,
>>  Seb
>>
>> --
>> Sebastien Vauban
>>
>>
>>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Torsten Wagner]

Hi,

Eric I lost a bit track of what was the final decsion. Guess a good
way to get back on track would be helping with the documentary. Any
tasks to do?

Torsten

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> Hi,
>
> Eric I lost a bit track of what was the final decsion. Guess a good
> way to get back on track would be helping with the documentary. Any
> tasks to do?
>

Tom has handled the documentation (thanks Tom!) so he would know better
than I if there are any outstanding documentation tasks.

As a means of catching up with the final decisions I would recommend
reviewing the two commit messages linked to from my email this morning
announcing the merge.

Another task which would be much appreciated would be to go through the
introduction to working with code blocks on Worg and update the syntax
as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html

Thanks for the offer! -- Eric

>
> Torsten

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Thomas S. Dye]

Aloha Torsten,

Let me clean up some loose ends in the documentation of standardized
keywords in org.texi later today.  Eric moves more quickly than I do and
the documentation is in a "working draft" stage, definitely not ready
for consumption and use.

I didn't get around to documenting the ability to accumulate properties,
so please have a go at that if you like.  I looked at it briefly and
thought that there should be an overview of the new functionality in
section 7.1, after the discussion of _ALL properties, and then details
in the section on Working with Source Code, where use of the
functionality with var=name should be explained.  I'm not too clear on
the other possibilities this functionality introduces, so my ideas here
might be wide of the mark.

All the best,
Tom


Eric Schulte <schulte.eric@gmail.com> writes:

> Torsten Wagner <torsten.wagner@gmail.com> writes:
>
>> Hi,
>>
>> Eric I lost a bit track of what was the final decsion. Guess a good
>> way to get back on track would be helping with the documentary. Any
>> tasks to do?
>>
>
> Tom has handled the documentation (thanks Tom!) so he would know better
> than I if there are any outstanding documentation tasks.
>
> As a means of catching up with the final decisions I would recommend
> reviewing the two commit messages linked to from my email this morning
> announcing the merge.
>
> Another task which would be much appreciated would be to go through the
> introduction to working with code blocks on Worg and update the syntax
> as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html
>
> Thanks for the offer! -- Eric
>
>>
>> Torsten

-- 
Thomas S. Dye
http://www.tsdye.com

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

The "cleaning up" documentation patch has now been applied.

Best -- Eric

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha Torsten,
>
> Let me clean up some loose ends in the documentation of standardized
> keywords in org.texi later today.  Eric moves more quickly than I do and
> the documentation is in a "working draft" stage, definitely not ready
> for consumption and use.
>
> I didn't get around to documenting the ability to accumulate properties,
> so please have a go at that if you like.  I looked at it briefly and
> thought that there should be an overview of the new functionality in
> section 7.1, after the discussion of _ALL properties, and then details
> in the section on Working with Source Code, where use of the
> functionality with var=name should be explained.  I'm not too clear on
> the other possibilities this functionality introduces, so my ideas here
> might be wide of the mark.
>
> All the best,
> Tom
>
>
> Eric Schulte <schulte.eric@gmail.com> writes:
>
>> Torsten Wagner <torsten.wagner@gmail.com> writes:
>>
>>> Hi,
>>>
>>> Eric I lost a bit track of what was the final decsion. Guess a good
>>> way to get back on track would be helping with the documentary. Any
>>> tasks to do?
>>>
>>
>> Tom has handled the documentation (thanks Tom!) so he would know better
>> than I if there are any outstanding documentation tasks.
>>
>> As a means of catching up with the final decisions I would recommend
>> reviewing the two commit messages linked to from my email this morning
>> announcing the merge.
>>
>> Another task which would be much appreciated would be to go through the
>> introduction to working with code blocks on Worg and update the syntax
>> as appropriate. http://orgmode.org/worg/org-contrib/babel/intro.html
>>
>> Thanks for the offer! -- Eric
>>
>>>
>>> Torsten

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3994 bytes --]

On Tue, Nov 15, 2011 at 5:00 PM, Eric Schulte <schulte.eric@gmail.com>wrote:

> Rainer M Krug <r.m.krug@gmail.com> writes:
>
> > Is that patch on git yet? i.e. if can I switch back to HEAD and change my
> > files accordingly?
> >
>
> Hi Rainer,
>
> I've must merged all of the pending code block changes into the master
> branch of the Org-mode git repository.  So now would be a good time to
> re-sync with the master branch.
>

Great news. I'll try and adapt my files then tomorrow and let you know if
there are any problems.

Thanks,

Rainer


>
> Best -- Eric
>
> >
> > Cheers,
> >
> > Rainer
> >
> >
> > On Wed, Nov 9, 2011 at 11:31 PM, Sebastien Vauban <
> > wxhgmqzgwmuf@spammotel.com> wrote:
> >
> >> Hi Eric,
> >>
> >> Eric Schulte wrote:
> >> > Rainer M Krug <r.m.krug@gmail.com> writes:
> >> >
> >> >> On Tue, Nov 8, 2011 at 11:53 PM, Eric Schulte <
> schulte.eric@gmail.com
> >> >wrote:
> >> >>
> >> >>> > Perhaps inserting an assumed space separator would be more
> intuitive?
> >> >>> > If we were to go that way it may be possible to allow variable
> >> >>> > specifications such as
> >> >>> >
> >> >>> > #+PROPERTY: var foo=1 bar=2
> >> >>> >
> >> >>> > in which case properties could be easily specified on multiple
> lines
> >> >>> > using a default space separator.
> >> >>> >
> >> >>> > If this seems like a good way to go I can try to update my
> previous
> >> >>> > patch.
> >> >>>
> >> >>> I've updated the patch, the newest version is attached.  It results
> in
> >> >>> the following behavior.
> >> >>
> >> >> Looks good to me - that leaves just the question, what would hppen
> when
> >> >> doing the following:
> >> >>
> >> >> #+property: var  foo=1
> >> >> #+property: var+ 2
> >> >
> >> > The above is equivalent to,
> >> >
> >> > #+header: :var foo=1 2
> >> >
> >> > which due to interaction with some logic put in place to allow the
> >> > specification of un-named variables in call lines results in the
> >> > following.
> >> >
> >> > #+property: var  foo=1
> >> > #+property: var+ 2
> >> > #+begin_src emacs-lisp
> >> >   foo
> >> > #+end_src
> >> >
> >> > #+results:
> >> > : 2
> >> >
> >> > #+begin_src emacs-lisp :var bar=1 2
> >> >   bar
> >> > #+end_src
> >> >
> >> > #+results:
> >> > : 2
> >> >
> >> > Although generally I would say that both
> >> >
> >> > #+header: :var foo=1 2
> >> >
> >> > and
> >> >
> >> > #+property: var  foo=1
> >> > #+property: var+ 2
> >> >
> >> > are mal-formed variable assignments.
> >>
> >> I was amazed, yesterday, when you told about `foo' becoming `12' (with
> `1'
> >> on
> >> the assignment line and `2' on the continuation), but I'm glad you
> consider
> >> this as rather ill-formed.
> >>
> >> >> and
> >> >>
> >> >> #+property: var  foo="Hello "
> >> >> #+property: var+ "world"
> >> >
> >> > This is exactly analogous to
> >> >
> >> > #+header: :var foo="hello" "world"
> >> >
> >> > which raises the expected error
> >> >   ``variable ""world"" must be assigned a default value''
> >> >
> >> > the following alternative however works as expected
> >> >
> >> > #+property: var  foo="Hello
> >> > #+property: var+ world"
> >> > #+begin_src emacs-lisp
> >> >   foo
> >> > #+end_src
> >> >
> >> > #+results:
> >> > : Hello world
> >>
> >> That said, all of these seem excellent trade-off between the different
> >> alternatives that have been discussed and analyzed, and they respect
> >> important
> >> aspects: simplicity (intuitive on reading) and powerfulness.
> >>
> >> Just perfect!
> >>
> >> Best regards,
> >>  Seb
> >>
> >> --
> >> Sebastien Vauban
> >>
> >>
> >>
>
> --
> Eric Schulte
> http://cs.unm.edu/~eschulte/
>



-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 6512 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Sebastien Vauban]

Hi Rainer,

Rainer M Krug wrote:
>> The proposal is, when a property name ends in +, the value is appended
>> to the corresponding property, rather than replacing it, so
>>
>>  #+PROPERTY: var   foo=1
>>  #+PROPERTY: var   bar=2
>>
>> results in '(("var" . "bar=2"))
>>
>>  #+PROPERTY: var    foo=1
>>  #+PROPERTY: var+ , bar=2
>>
>> results in '(("var" . "foo=1, bar=2"))
>>
>> This way subtree properties could be used as well, e.g.,
>>
>>  #+PROPERTY: var foo=1
>>
>>  * subtree
>>    :PROPERTIES:
>>    :var+: bar=2
>>    :CUSTOM_ID: something
>>    :END:
>
> I like that suggestion - it is clear, easy to understand, gives other
> advantages (you can "unset" variables in a subtree - which would be an
> added bonus) and does not require any large changes in org files.

How do you unset a var?  By resetting the list with a new var (without `+'),
and adding all the other valid vars?  If so, not really unsetting... You
simply void all vars, and create new definitions...

Best regards,
  Seb

-- 
Sebastien Vauban

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1749 bytes --]

On Tue, Nov 8, 2011 at 10:41 AM, Sebastien Vauban <
wxhgmqzgwmuf@spammotel.com> wrote:

> Hi Rainer,
>
> Rainer M Krug wrote:
> >> The proposal is, when a property name ends in +, the value is appended
> >> to the corresponding property, rather than replacing it, so
> >>
> >>  #+PROPERTY: var   foo=1
> >>  #+PROPERTY: var   bar=2
> >>
> >> results in '(("var" . "bar=2"))
> >>
> >>  #+PROPERTY: var    foo=1
> >>  #+PROPERTY: var+ , bar=2
> >>
> >> results in '(("var" . "foo=1, bar=2"))
> >>
> >> This way subtree properties could be used as well, e.g.,
> >>
> >>  #+PROPERTY: var foo=1
> >>
> >>  * subtree
> >>    :PROPERTIES:
> >>    :var+: bar=2
> >>    :CUSTOM_ID: something
> >>    :END:
> >
> > I like that suggestion - it is clear, easy to understand, gives other
> > advantages (you can "unset" variables in a subtree - which would be an
> > added bonus) and does not require any large changes in org files.
>
> How do you unset a var?  By resetting the list with a new var (without
> `+'),
> and adding all the other valid vars?  If so, not really unsetting... You
> simply void all vars, and create new definitions...
>

Exactly - with "unseting" var, I don't refer to unsetting a single
variable, but all variables.

But as we have the var+, what about a var- to unset a single variable?


>
> Best regards,
>  Seb
>
> --
> Sebastien Vauban
>
>
>


-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology,
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax (F):       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

[-- Attachment #2: Type: text/html, Size: 2723 bytes --]

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

>>
>> How do you unset a var?  By resetting the list with a new var
>>(without `+'),

See, the example in my original email, a property with var (no "+")
wipes out any previously existing var properties.

>> 
>> and adding all the other valid vars?  If so, not really
>> unsetting... You simply void all vars, and create new definitions...
>>

yes

>>
>
> Exactly - with "unseting" var, I don't refer to unsetting a single
> variable, but all variables.
>
> But as we have the var+, what about a var- to unset a single variable?
>

This is not possible.  Up until this point we continue to treat the var
property as any other property, and we just allow the construction of a
long var value, such as "foo=1, bar=2, baz=3".  Introducing a var- would
be a large departure from current property handling and would require
parsing lines like the above.

Best -- Eric

>
>
>>
>> Best regards,
>>  Seb
>>
>> --
>> Sebastien Vauban
>>
>>
>>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Samuel Wales]

Something that has not been mentioned yet, as a possible
background.

One nice thing about subtrees (the properties drawer) for
control is that they are nicely (essentially lexically)
scoped and nested as in many programming languages.

One issue with blocks for control is that they are
ambiguously scoped.

  - It isn't immediately clear whether they apply to the
    whole file or below the block.
    + If they apply to the whole file, it can be confusing
      to have them hidden in some subtree but have global
      effect.  Moving a subtree into the file can
      surprisingly change state for all other subtrees.
    + If they apply below the block, and you sort subtrees,
      those that used to be above or below surprisingly
      change state.


Of course those who work on a file basis still need some way
of specifying control for the file.  And that can be at the
top of the file.  I am not saying there should be no way to
do that.  Just pointing out something not yet mentioned in
these threads.

Maybe scoping is one reason underlying the unease some have
with using blocks for control where there is no equivalent
subtree option.

I avoid file-level operations partly for that reason.

===

One interesting possibility is to have a dedicated top-level
entry for all file-level control purposes.  Then it's clear
where everything should go, and syntax can even follow the
subtree syntax.

However, that might be too radical for this discussion.


Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Samuel Wales]

A followup on my second point.

On 2011-11-02, Samuel Wales <samologist@gmail.com> wrote:
> ===
>
> One interesting possibility is to have a dedicated top-level
> entry for all file-level control purposes.  Then it's clear
> where everything should go, and syntax can even follow the
> subtree syntax.

Thus, for example, a tag on that entry becomes a file tag.  To
understand file-level syntax, you only need to understand tags and
property drawers as usual.

There is no need to RTFM the syntax for how to do a file-level
operation, because you already know it for subtrees.

>
> However, that might be too radical for this discussion.
>

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Bastien]

Dear Samuel,

I like the way you frame the issue and the solution you 
are sketching.

I am not fund of a "dedicated top-level entry for all 
file-level control purposes" because it transforms the 
ambiguity about keywords' scope into an ambiguity about 
structure: IMHO a subtree should never be something that
you always want to remove when exporting.

But allowing a top-level :PROPERTIES: drawer with properties 
whose scope is the entire file looks like a good idea to me.

How other would feel about this?

-- 
 Bastien

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Christian Moe]

On 11/3/11 2:42 AM, Bastien wrote:

> But allowing a top-level :PROPERTIES: drawer with properties
> whose scope is the entire file looks like a good idea to me.
>
> How other would feel about this?
>

Not sure if this is already clear, but just in case: The functionality 
is already there. PROPERTY lines set buffer-wide properties.

This works now:

#+TITLE: My foobar file
#+PROPERTY: foo 1
#+PROPERTY: bar 2
#+PROPERTY: baz 3

Replacing it with a top-level property drawer before the outline would 
make another bit of syntax redundant, and it would sometimes save a 
bit of typing (if there are many buffer-wide properties tobe set):

#+TITLE: My foobar file
:PROPERTIES:
:foo: 1
:bar: 2
:baz: 3
:END:

I have come to expect that any file-wide settings are in #+... lines 
and that any property drawers are associated with outline entries. I 
don't know how important it is to maintain those expectations.

Yours,
Christian

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

>
> But allowing a top-level :PROPERTIES: drawer with properties
> whose scope is the entire file looks like a good idea to me.
>

I don't see what this would add, how would this solve the need for
multi-line properties, and how would it differ from IMO being uglier
than a series of #+PROPERTY: lines.

Best -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Eric Schulte]

While I still think `org-accumulated-properties-alist' is the most
powerful solution -- as it is the only solution which allows a subtree
property block to extend rather than overwrite a file-wide property.
I've been thinking a little bit more about these issues and I'm
returning to a previous suggestion...

Do we still think that using #+KEYWORD+: lines is an ugly way to specify
multi-line values for keywords.  I think this has the advantages of
simplicity, intuitiveness (its use is obvious once you see it), and
generality (i.e., this could be used to allow multi-line tblfm lines).

Just another thought -- Eric

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: About commit named "Allow multi-line properties to be specified in property blocks"

[Samuel Wales]

Hi Eric,

On 2011-11-03, Eric Schulte <schulte.eric@gmail.com> wrote:
>>
>> But allowing a top-level :PROPERTIES: drawer with properties
>> whose scope is the entire file looks like a good idea to me.
>>
>
> I don't see what this would add, how would this solve the need for
> multi-line properties, and how would it differ from IMO being uglier
> than a series of #+PROPERTY: lines.

(Your quote is from Bastien, not me.)

The idea the way I put it (which is with a top level entry to hold the
properties drawer) is, as I stated, possibly too radical for the
thread.  Possibly too radical period.  So feel free to ignore it.

However, let me clarify because I think you might misunderstand.

The idea is not to augment syntax, but reduce it.  Or, if backward
compatibility is desired, then reduce the need for future
ambiguous-scope syntax -- which is a currently unresolved problem.

In my view #+ is uglier than existing property syntax -- which has to
exist anyway because it is used for all sorts of things.  You can't
get rid of it.  (And shouldn't.)

The idea is that a single top-level task, marked as such, acts as if
it were a superlevel, and contains ALL information needed for the file
level.

So there will be no need for #+property .

It is consistent syntax with the rest of Org, unlike file-level or
rest-of-file #+ syntax.  It is less ambiguous in scope.  It is clear
what it means.

It is foldable.  It is searchable the same way other entries are searchable.

The agenda can show it if you want it to (unlike #+whatever).

More consistent all the way around IMO.

If I were designing Org from scratch, I probably would not suggest
this.  Instead, I would simply disallow file-level anything.  If you
want that, just use a top-level task.  a/b/c -- you know, normal
outline.  And then export that top level subtree.

To me, and this is admittedly radical, file-level operations should be
deprecated.

But as a compromise, since a lot of people do file-level operations, I
am proposing a dedicated top level place that acts as if it is
hierarchically above everything else even though it is not.  That
allows consistency better than #+property IMO.

I am talking about the stuff at the top of the file (title,
properties, etc.)  Not blocks etc.  Those are reasonable elsewhere.

As for multiple-line properties, you can use the syntax you're
currently discussing to accumulate in the properties drawer, or even
use a syntax to simply allow multiple-line properties in a properties
drawer.  Either way.

Again, probably too radical for this thread, but I wanted to clarify.

Hope that clarifies.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
===
Bigotry against people with serious diseases is still bigotry.