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