[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] About commit named "Allow multi-line properties to be specified
From: |
Eric Schulte |
Subject: |
Re: [O] About commit named "Allow multi-line properties to be specified in property blocks" |
Date: |
Tue, 01 Nov 2011 10:58:27 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) |
Nicolas Goaziou <address@hidden> writes:
> Eric Schulte <address@hidden> 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.
0001-Allow-some-properties-to-accumulate-see-org-accumula.patch
Description: Text Data
>
>
> Regards,
--
Eric Schulte
http://cs.unm.edu/~eschulte/
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Nicolas Goaziou, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Nicolas Goaziou, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Eric Schulte, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Nicolas Goaziou, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks",
Eric Schulte <=
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Christian Moe, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Eric Schulte, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Christian Moe, 2011/11/01
- Re: [O] About commit named "Allow multi-line properties to be specified in property blocks", Eric Schulte, 2011/11/01