Ihor Radchenko writes: > Tyler Grinn writes: > >> Ihor Radchenko writes: >> >>> Tyler Grinn 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 OK, what I have now is that if the car of an alist item is a list, exact matching will be done for each list item, but if it is a string, it will be matched as a regular expression. Best, Tyler