Tyler Grinn <tylergr...@gmail.com> writes:

> Ihor Radchenko <yanta...@gmail.com> writes:
>
>> Tyler Grinn <tylergr...@gmail.com> writes:
>>
>>>
>>> Could you provide an example of what the value of that variable would be
>>> if, for instance, I wanted PROP_A and PROP_B to be joined with a single
>>> space and PROP_C and PROP_D to be concatenated? Or better yet, have the
>>> default be to join with a single space for any property and have only
>>> PROP_C and PROP_D concatenated?
>>
>> Say,
>>
>> '(("PROP_[CD]" . ""))
>>
>> or
>>
>> '(("PROP_[AB]" . "/") ("PROP_[CD]" . "") (".+" . "∿"))
>>
>> Best,
>> Ihor
>
> I'm not sure forcing regular expressions for all use cases is ideal. Is
> there a way to allow the option (I'm calling it org-property-separators)
> to allow either regular expressions or exact matches, like
> org-use-property-inheritance does?

It's up to you. I merely suggested that the new option should work
similarly to org-use-property-inheritance. It will not be the exact
match since we also need to provide the separator string.

> Other than that I'm mostly ready to send in my first patch. Should I
> attach it in this thread or start a new one?

Keeping the patch within this thread will be more reasonable for future
readers. Just remember to prefix the subject line with [PATCH].

Best,
Ihor


Reply via email to