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

[Cassio Koshikumo]

Ah! Can't believe I didn't try that. Well, at least the docs can
benefit from my confusion.

Thanks,

On Wed, Aug 25, 2021 at 6:05 PM Daniel Fleischer <danflscr@gmail.com> wrote:
>
> 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*



-- 
Cassio Koshikumo