Re: org-agenda queries for absent properties

[Ihor Radchenko]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> - I used "\(?NUM: ... \)" constructs to explicitly number the subres.
>    Hope this is OK w.r.t. style and backward-compatibility.

Yes, it is ok.

> - I fixed the operator-matching subre to also include `==', `!=', `/='
>    but exclude `<<' and the like which currently give void-function
>    errors.

Sounds reasonable.

> But from here it gets more intersting:
>
> - The code uses subre "\\\\-" in property names to (supposedly) allow
>    for inclusion of minus characters in property names, which (probably)
>    could be confused with term negation.

Not probably. It is known to be confused.
https://orgmode.org/list/87jzv67k3p.fsf@localhost

> - It also unquotes these minus characters for {tag regexps}:
>
>      (tag (save-match-data
>             (replace-regexp-in-string
>              "\\\\-" "-" (match-string 2 term))))
>
>    But it never unquotes them in property names.  That missing unquoting
>    could be easily amended, but:
>
> - The other issue is: Why do we need "\\\\-" for both property names and
>    {tag regexps}?  This forces us to do queries like:
>
>      {[a\\-z]}|foo\\-bar="baz"
>
>    where in my opinion
>
>      {[a\-z]}|foo\-bar="baz"
>
>    should be sufficient.

Ideally, we should have no need to quote "-" inside regexp terms.
The need to do it is not documented either.

> - Even more, IMO one could do away completely with the minus-quoting and
>    unquoting, since the overall regexp should allow for unambiguously
>    matching minus characters both
>
>    + in {tag regexps} (because of "{[^}]+}" gobbling them) and
>
>    + in property names (because a property name must always be followed
>      by some operator)
>
>    *without* them getting confused with term negation.
>
>    Or do I miss something here?  A cursory test with sth like
>
>      +foo-bar="xxx"-patchday=202302
>
>    seems to work fine.

Agree.

> - However, removing the unquoting of {tag regexps} would be a breaking
>    change.  Even though I doubt anybody has ever used it, the more it is
>    not mentioned in the documentation.

Unquoting in {tag regexps} was never intentional.
The commit that introduced this piece of code is the following:

19b0e03f32c6032a60150fc6cb07c6f766cb3f6c
Author:     Carsten Dominik <carsten.dominik@gmail.com>
Make backslash escape "-" in property matches

* lisp/org.el (org-make-tags-matcher): Read "\\-" as "-" in
the tags/property matcher.

Ilya Shlyakhter writes:

 When doing an agenda tags match for tags or properties with dashes in
 their name, the dashes become negation operators: "my-prop>0" means
 "entries that have the tag 'my' and do not have a positive property
 'prop'", rather than "entries that have a positive property
 'my-prop'".  Is there a way to escape the dashes to get the latter
 meaning?

> +              ;; LEVEL property match
> +              "LEVEL\\(?3:[<=>]=?\\|[!/]=\\|<>\\)\\(?4:[0-9]+\\)\\|"
> +              ;; regular property match
> +              "\\(?:"
> +                  ;; property name
> +                  "\\(?5:\\(?:[[:alnum:]_]+\\(?:\\\\-\\)*\\)+\\)"
> +                  ;; operator, optionally starred
> +                  "\\(?6:[<=>]=?\\|[!/]=\\|<>\\)\\(?7:\\*\\)?"

?3 and ?6 duplicate a part of regexp. It would make sense to let-bind
the common part to avoid accidental typos in future.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>