Eric Schulte <schulte.e...@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