From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id COW0EjwW8mSgCAEAauVa8A:P1 (envelope-from ) for ; Fri, 01 Sep 2023 18:50:04 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:478a::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id COW0EjwW8mSgCAEAauVa8A (envelope-from ) for ; Fri, 01 Sep 2023 18:50:04 +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 4804F66624 for ; Fri, 1 Sep 2023 18:50:03 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=jufNeXYW; 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=quarantine) header.from=vodafonemail.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1693587004; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=oSMzGl2Kka1JCHp/m/wh8BFFxvTVxrTaAuSRd8Jaors=; b=IUYBKbwjxaFBEKmGvqt5REbLw/J8IQqyJXkiOQpReA+bgXyk5Tg2tf3gseIHI2aiS15myO +hVWrRkVzA+jEsggD2+CdCchMBhqAYFwOZqyE86cWHh/zinR05HBvkrpf/xR7GSpxkMZko tC2V6qWtlzTStkC1SMv1ekpjWI2vk63VDzIl+LQ9G3wNrfdsRf2wnlGyXM+9eipiQ1cQNm xIubyBqeLjxp5UVlTEhwmYF7/7Y9UvXPJeO83fcWjfMq2YTrwy3lhqyEjcqPX/SYYdObml Es8cJZ5z7n1sjcppcFERevXKQW5BkSJN8VYRDWIk8umxNZPd3mVVwQjDx4UKtQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=vodafonemail.de header.s=vfde-mb-mr2-21dec header.b=jufNeXYW; 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=quarantine) header.from=vodafonemail.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1693587004; a=rsa-sha256; cv=none; b=dkbDCEoMMtTYuTSyh62hkU26w21Up8viZaVjeKJCTxlSXiz+6ijosko0uyC7iti7hF3kl+ 8Rtef58Mo3/Do85KT2FqY8C+yEm9T7O6nHJ2avLdGb0PeFSdkLN/s40SexSI2f2z3QZCOv zMjxN4xQ9oNkG1jfrQk1dduvIASZhRMAu/idQ7SQ3X9+58RgxS8WbpCGOPYWnPNkNzOzE1 PRtnAyvk7IlDOEhk3NyNcnejbNIthA0x6vmIP9maZCMETZ2kD/FlW2WlWfwNUNMlbTPhg9 Gvf8h32Bqtpw1Oop3+F0FJqIWUPob1eYF00k/DXXPCjaxWW9Sc3BNaW4CJco+w== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qc7KW-0004FD-38; Fri, 01 Sep 2023 12:49:08 -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 1qc7KU-0004ER-0H for emacs-orgmode@gnu.org; Fri, 01 Sep 2023 12:49:06 -0400 Received: from mr4.vodafonemail.de ([145.253.228.164]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc7KR-000628-5T for emacs-orgmode@gnu.org; Fri, 01 Sep 2023 12:49:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vodafonemail.de; s=vfde-mb-mr2-21dec; t=1693586935; bh=oSMzGl2Kka1JCHp/m/wh8BFFxvTVxrTaAuSRd8Jaors=; h=Message-ID:Date:User-Agent:Subject:Content-Language:To:References: From:In-Reply-To:Content-Type:From; b=jufNeXYWzaGOOUMK2IfwXHWKhntxYzvYiK1SFKS7yqEjdwDdcjEoNhIDUYTLbKzM6 kqSz7poHJZVdqa8nKORZlQlt0kwTn9fJOIHPCA2D+4JYTj+qYCdpeZdh/j9mejef/f Vj3csckCxeiKtv6jHIFT7EqtAtLBz3Jp1y2fVZrA= Received: from smtp.vodafone.de (unknown [10.0.0.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mr4.vodafonemail.de (Postfix) with ESMTPS id 4RckWW55zSz1y8G; Fri, 1 Sep 2023 16:48:55 +0000 (UTC) Received: from [192.168.0.138] (unknown [86.33.89.202]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.vodafone.de (Postfix) with ESMTPSA id 4RckWJ3RGmzHpxb; Fri, 1 Sep 2023 16:48:41 +0000 (UTC) Message-ID: <2937cbf6-4ee7-0bdc-b585-d74c9d80883b@vodafonemail.de> Date: Fri, 1 Sep 2023 18:48:32 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property] Content-Language: de-DE-frami, en-US To: Ihor Radchenko , Samuel Loury Cc: emacs-orgmode@gnu.org References: <87h6oq2nu1.fsf@gmail.com> <877cpm6oe3.fsf@localhost> <811c9bda-cea4-c0d6-30b4-53ebdb432ab6@vodafonemail.de> <748acab1-eaf4-fdd3-13a6-26e6229de613@vodafonemail.de> <87o7iw7v4q.fsf@localhost> <98f4101b-7281-2793-ca30-7086c4f10c5d@vodafonemail.de> <87sf86w1k8.fsf@localhost> <6a7888b5-1b4c-9a59-8a8e-e27c9d8b50cb@vodafonemail.de> <87h6omj9nx.fsf@localhost> <87edjqj8mk.fsf@localhost> <878r9xez7m.fsf@gmail.com> <874jklhqw2.fsf@localhost> From: Jens Schmidt In-Reply-To: <874jklhqw2.fsf@localhost> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-purgate-type: clean X-purgate: clean X-purgate-size: 2883 X-purgate-ID: 155817::1693586931-037FF18D-4FFC9B29/0/0 Received-SPF: pass client-ip=145.253.228.164; envelope-from=jschmidt4gnu@vodafonemail.de; helo=mr4.vodafonemail.de X-Spam_score_int: -62 X-Spam_score: -6.3 X-Spam_bar: ------ X-Spam_report: (-6.3 / 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, NICE_REPLY_A=-3.478, RCVD_IN_DNSWL_LOW=-0.7, 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.83 X-Spam-Score: -6.83 X-Migadu-Queue-Id: 4804F66624 X-Migadu-Scanner: mx0.migadu.com X-TUID: XoOaAMG0I+wH On 2023-08-27 09:43, Ihor Radchenko wrote: > Samuel Loury writes: > >> IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that >> & and | are forbidden to say anything else than AND and OR and people >> would be ok with that. > > Actually, explicit & or | might be an easier way to not worry about > escaping things. Except escaping & or | themselves. > It might be the preferred way to put into the manual. > >> IOW, I wonder of the time and effort to deal with optional & is worth >> it. WDYT? > > We cannot remove the optionality of &, because doing so will break > existing user setups. But we can certainly change our recommendations in > the manual. > > Though pure tag matcher makes more sense with implicit &: > +tag1-tag2+tag3... vs +tag1&-tag2&+tag3 > Especially in the interactive agenda filters. I feel it's a bit hard to reply to this message in the right places, so I'll do a plain bottom post, sorry. TL;DR: - I think we cannot make "&" mandatory because of backward compatibility. - Even if we made "&" mandatory, it would not really solve the quoting problem, since the parser is rather hacky and other quoting and context issues would still be there. - But then I cannot see any real reason why we should recommend using "&" in the manual. - Finally, we should hope for and work towards a "real parser", as Ihor has mentioned already in a previous post: (beginning of thread) https://list.orgmode.org/orgmode/9132e58f-d89e-f7df-bbe4-43d53a2367d2@vodafonemail.de/ (mentioning of peg) https://list.orgmode.org/orgmode/87wmyendr7.fsf@localhost/ Details, as far as still required: The whole tag/property query parser seems to have a long tradition. For example, there is still that TODO-state special case that allows for queries like this (example ripped from the manual): work/WAITING Same as work+TODO​="WAITING" So people *have* been worrying about a) query brevity and b) backward compatibility, and I think we should do so as well. Then the current parser is horribly ad-hoc-ish and, as a plain regexp-based parser, context insensitive. For example, a tag regexp match {regexp} is matched simply as {[^}]+} that is, you have no chance whatsoever to quote the closing curly parenthesis. Likewise for double-quoted strings. In other words, even if we make | or & mandatory, there will still remain a lot of ambiguities stemming from the rest of the parser. And I'm too lazy to think about how we could quote & in that whole picture. (| is sort of handled already, but again in a completely context-insensitive way.) This all calls for a proper parser, based on peg or bovine or whatever. Hopefully that parser would still keep backward compatibility, but that's probably wishful thinking.