From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id KK7YKBNSz2QcYwEASxT56A (envelope-from ) for ; Sun, 06 Aug 2023 09:56:03 +0200 Received: from aspmx1.migadu.com ([2001:41d0:306:2d92::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id wDp4KBNSz2SNNQAAauVa8A (envelope-from ) for ; Sun, 06 Aug 2023 09:56:03 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 920374C021 for ; Sun, 6 Aug 2023 09:56:02 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GjjwZ3ZG; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1691308563; a=rsa-sha256; cv=none; b=uE/pYO2UwB1f0C8PeJZaqDH8aYNkXddKhDYPzqVnXCjdOQM2VJSzf0FVeW6HBKohBlbWjx fhN5w7Fzam5uf7VPp4DwhFXNEP2Tn00WqlkvWznxuyrkD6V7NlK/7yi/1EJ+ATItTJK+Gy sU2NZiA/qgNAKIEMltS363ckGWVEtuwxU7OV0hUnr3PtfLG9O/sUS5VqFzzwe7WRA00cZ7 oRdKdABKsL0k3he5VuJlkBhDULKfgb8AD6N72xdMBGCTnihMsIN3yNMQZs/hegxEYb2/ZR HT0x5tXQj0IsEMUgJyCGmHHmIWUcRhf1zsEpMCoUSBhdj86Sk9J67ieekfCj2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1691308563; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=/CJCOnJMg9I0tKh/UJ8IG+nMxonjULdrSz+ArurTi5w=; b=E7+POJHcpIQeT5LlXZ4sK0cntXgak1bQbwaZg9E+2WrjXs9FBAD/kOw8x6bCfP1b47ZGmv 3PTMx5t/yA+aGCArlfoDV2lHwiDq8RS7ntBM+uthu5peeOsqIw2T/cc7+rrcZWUjonRqQv ZtHVRTFinF7V9KcbXJbhvYRct/iWNXO6l95p+6a/15m2EOfLPVfqPK0mwrbwSrPEgT/WWj ly+CxVudRJNvsiCk7p6Msg4eALewS3NoGWvOEk3xjcGvzvQY+l5dkH9kuKnXvgNW8cfubi /gGGmpeEs38cEB/2Bd+x/Swab/qvCwzlsbL0VN7aFMXZFUYE4BOqr6wipHzRwQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=GjjwZ3ZG; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.net Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qSYbN-0004xs-32; Sun, 06 Aug 2023 03:55:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSYbK-0004xX-VD for emacs-orgmode@gnu.org; Sun, 06 Aug 2023 03:54:58 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qSYbH-00020r-EJ for emacs-orgmode@gnu.org; Sun, 06 Aug 2023 03:54:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B01FC240101 for ; Sun, 6 Aug 2023 09:54:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1691308490; bh=4SxInZxzJKGA0HPRjBh/HRfbOlToYhGh/l2yPokOjCk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=GjjwZ3ZG2aHUeRcg/WuRCBH3itH6cRSydiEFTb+vRzTVF0OX8oPQUpXSokY4ttrOI Zqn8kn+pWSQucP+JzQdcwMeUTyjOOgP8IxeWtBmKY1weVM3ZSPZpelpLHUOBx1fqCY SWSgmLgmko0iQOjkFspugbVL8kG4qQWKr17VUC8q2StO2pP3x5faWgVui8+eZyuKhy 6VkLgkes3A7HbkA3SC5DF11IaLQxwPWa6fdngpyS3dPauqsYm9WLWfcezyyq1ZJnKY 74S9kJZ+zTn2zUAyOpUYNgxUeeT66P8dnI4hx1aoVNDdqK7FejYmAFcofKRLWJYJA7 x1KXVIzSt6Fjw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RJWvG0VRDz6trs; Sun, 6 Aug 2023 09:54:49 +0200 (CEST) From: Ihor Radchenko To: Jens Schmidt Cc: Org-mode Subject: Re: org-agenda queries for absent properties In-Reply-To: <8c28a287-1a00-4bd2-7180-57e769425e85@vodafonemail.de> References: <9132e58f-d89e-f7df-bbe4-43d53a2367d2@vodafonemail.de> <87o7jsinoo.fsf@localhost> <3ac83971-2805-cfde-28a3-891814b95c25@vodafonemail.de> <87wmyendr7.fsf@localhost> <8c28a287-1a00-4bd2-7180-57e769425e85@vodafonemail.de> Date: Sun, 06 Aug 2023 07:55:14 +0000 Message-ID: <87r0ogip0d.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -6.32 X-Migadu-Scanner: mx2.migadu.com X-Migadu-Queue-Id: 920374C021 X-Spam-Score: -6.32 X-TUID: toJD27zL3eUm Jens Schmidt 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 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 . Support Org development at , or support my work at