On Wed, Aug 25 2021, Cassio Koshikumo wrote: > Hello all, > > I think there's a bug with `org-make-tags-matcher' when creating a sparse tree > using property matching with regular expressions and "or" terms. Take the > example given in the manual: > > +work-boss+PRIORITY="A"+Coffee="unlimited"+Effort<2 > +With={Sarah|Denny}+SCHEDULED>="<2008-10-11 Sat>" > > If we isolate just this part: > > +With={Sarah|Denny} > > The resulting sparse tree does not match the right > headings. The function generates the following `tagsmatcher': > > (progn > (setq org-cached-props nil) > (or > (and > (member > #("Denny" 0 5 > (regexp t)) > tags-list)) > (and > (member "With" tags-list)))) > > There're checks for "Denny" (as a regexp) and "With" (as a string) --- this is > supposed to be the property name, not a search term. They are both checked for > in `tags-list'. And, finally, "Sarah" is nowhere to be seen. > > The problem, as far as I can tell, is that splitting the input at `|' to get the > `orterms' does not work with the regular expression the function uses to find > the constituent parts of each term. In this example, splitting the input at `|' > makes one side get the opening brace and the other the closing brace, while the > regexp expects both being present. Since the regexp doesn't fully match, the > terms are all parsed wrong. (The function doesn't recognize "With" as property > name, for instance.) I'm still messing with it but, for now, don't really know > how to fix the problem. I don't 100% understand the function yet... > > Regards, Hi, the solution is that it's elisp based regex, so OR is indicated with \| instead of just |. It might be good idea to correct the example. Best, *Daniel Fleischer*