Re: [BUG] Creating sparse tree with regexp property matches

[Daniel Fleischer]

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*