Nicolas Goaziou writes: > Eric Schulte 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.