From: Ihor Radchenko <yantar92@posteo.net>
To: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
Cc: Org-mode <emacs-orgmode@gnu.org>
Subject: Re: org-agenda queries for absent properties
Date: Sun, 06 Aug 2023 07:55:14 +0000 [thread overview]
Message-ID: <87r0ogip0d.fsf@localhost> (raw)
In-Reply-To: <8c28a287-1a00-4bd2-7180-57e769425e85@vodafonemail.de>
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>
next prev parent reply other threads:[~2023-08-06 7:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-30 17:13 org-agenda queries for absent properties Jens Schmidt
2023-07-31 6:45 ` Ihor Radchenko
2023-08-01 18:50 ` Jens Schmidt
2023-08-02 6:45 ` Ihor Radchenko
2023-08-05 10:56 ` Jens Schmidt
2023-08-06 7:55 ` Ihor Radchenko [this message]
2023-08-06 9:19 ` Jens Schmidt
2023-08-06 14:42 ` Jens Schmidt
2023-08-07 11:53 ` Ihor Radchenko
2023-08-07 20:20 ` Jens Schmidt
2023-08-08 7:04 ` Ihor Radchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r0ogip0d.fsf@localhost \
--to=yantar92@posteo.net \
--cc=emacs-orgmode@gnu.org \
--cc=jschmidt4gnu@vodafonemail.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).