emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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>


  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).