From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id +JrtBv18OmIX8gAAgWs5BA (envelope-from ) for ; Wed, 23 Mar 2022 02:50:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id MJ9eBP18OmICbAEA9RJhRA (envelope-from ) for ; Wed, 23 Mar 2022 02:50:53 +0100 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 2ED95FEB1 for ; Wed, 23 Mar 2022 02:50:52 +0100 (CET) Received: from localhost ([::1]:35682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWq9C-00029o-R8 for larch@yhetil.org; Tue, 22 Mar 2022 21:50:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWq8R-00029O-6s for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 21:50:03 -0400 Received: from [2607:f8b0:4864:20::1030] (port=39703 helo=mail-pj1-x1030.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWq8P-0004ZM-BC for emacs-orgmode@gnu.org; Tue, 22 Mar 2022 21:50:02 -0400 Received: by mail-pj1-x1030.google.com with SMTP id mr5-20020a17090b238500b001c67366ae93so4998773pjb.4 for ; Tue, 22 Mar 2022 18:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=J49YUpnCauN/7jBlCFaJmcyIVU/UuyL14SHJ9pooyyY=; b=mLG7/geJu0ISF/Z+mc89KNW27KyTrw8hrW/puBXiQUXqCZWp605GioPOWSp7h9J06p wyP6l9IgzlFIe3jF0pfH6wMbL7pQrjzUnwI0k3enIdVPcNUjP/T/S08o5ZVDS+lj9roJ 4kSYVP+L5EK2R+qoBDz/wubarbGN0s0W4F6P7jds2ew7y0VTkXlzpuAXxs4vNFbBXRYU eFIdB2ELGiECzaFQ+JJxZ4V8kkvMgV7qH5fHH6THX74tpHNfkQPDJUQtQEORpBNNgR+V +2i3HXL91Q/0Rv2SLiAIuaysD9n/EHyDpvJ1sfBY6O/OeEVhlcrOIBWmZB9izH0oNO+z 5Lhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=J49YUpnCauN/7jBlCFaJmcyIVU/UuyL14SHJ9pooyyY=; b=QNM0UKMSJka6dyvuLLu4K5Z9Tg1eijYrGw/3fWdWuSfvCYbZ0rmG/YemEZcpWqnZgc feMVc8RZZclaE00JV2m9BijVXvqlyJNwmoapZUgpBd/6dHOBIUNcMearTrAYo0RDI/Ba SGoMI3S2D9E+/w7MbzfkFJWcmAiLAS++qAB0FIF/xhjDGZeH3mBcEhvDudT+5OaB0Nl0 LhqepuD3uyipHvpakvkNxWjnfZ5P0PFAHNvmpLxwEcvRcUN317xf4+15KU7R1+UEC+dd AW+M+tthAPyn2Ml9LLAK7SwBEsWXHRPxm50xTmPo1wmx9araVv2HFkME2TpmTEcvaA6g thpA== X-Gm-Message-State: AOAM530EQHHgiwG5xe1Z1pDbutY77NtpolYx9eUCzabriirfoMZZrMoC j/yS4i9phKzHcvPLl36T+FOJuyKyOtgKyQ== X-Google-Smtp-Source: ABdhPJyzMTN7CFDEsd6IGjMPXKK6FzLKMGkVXuBEtTzs5WQkVSRdgm6NUdzU6x6g1yOxKAe4YoK47Q== X-Received: by 2002:a17:90a:c782:b0:1bc:dac0:88e with SMTP id gn2-20020a17090ac78200b001bcdac0088emr8553083pjb.172.1648000199392; Tue, 22 Mar 2022 18:49:59 -0700 (PDT) Received: from dingbat (220-235-26-154.dyn.iinet.net.au. [220.235.26.154]) by smtp.gmail.com with ESMTPSA id h6-20020a636c06000000b00363a2533b17sm18249350pgc.8.2022.03.22.18.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Mar 2022 18:49:58 -0700 (PDT) References: <87v8wje4nd.fsf@localhost> <066001d83d3c$7b463380$71d29a80$@tomdavey.com> <87tubqmi94.fsf@localhost> <87r16umhnj.fsf@localhost> <87pmmdsm2f.fsf@gmail.com> <075801d83e42$eea0aa20$cbe1fe60$@tomdavey.com> User-agent: mu4e 1.7.10; emacs 28.0.92 From: Tim Cross To: tom@tomdavey.com Subject: Re: Timestamp parsing inside node properties and other contexts out of org-element-object-restrictions (was: [BUG] Agenda no longer works for timestamps inside properties drawer [9.5.2 (release_9.5.2-24-g668205 @ /home/ignacio/repos/emacs/lisp/org/)]) Date: Wed, 23 Mar 2022 11:25:14 +1100 In-reply-to: <075801d83e42$eea0aa20$cbe1fe60$@tomdavey.com> Message-ID: <87h77psaik.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::1030 (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=theophilusx@gmail.com; helo=mail-pj1-x1030.google.com X-Spam_score_int: -6 X-Spam_score: -0.7 X-Spam_bar: / X-Spam_report: (-0.7 / 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, FREEMAIL_FROM=0.001, PDS_HP_HELO_NORDNS=0.659, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no 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: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1648000252; 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=J49YUpnCauN/7jBlCFaJmcyIVU/UuyL14SHJ9pooyyY=; b=U3N6N9HSREkL7rp/0e+VaYRs3Bbn29heETbbHeQpT7IYT/6RUAlgLamxAy47bgmMOZY//z HdDqlGy+Z2aie7/iE4qXZPNRo2vGXiyhAJ7C12iX312G2VbTSQ5bPJ9Yx2kTFFSxq6LR9T J8FqjwA4PpSMVQyh2j9W9S+E6w8ConETx9YXBwClCV0Gst6MgBHnx+UURdCcIsjgo2oa3A yvBtVa3Vyl7UciDATSbHA2//TfJoPwrl0Ocb1kuwuTNbtYvZ9zNIK0PxAUyx1xf00A701Y ahGzQLCbQh7egkRm9qij3A1GQl9PAb6fsgG9Z0xp1mAzjewPstVgdjQlQrz85g== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1648000252; a=rsa-sha256; cv=none; b=brdLZSXJ8lpZYBarPYKNEfvGNFGgZf/90SoW00/iZ7xCyfJcF0NLCXS5DSc1iLxbRtRYxW 7B7LdBqwF/WTzpQNi2diB787Nqv7ZGG85nlO41RKCUn/UrDTrXwnqZf7c298kZeSC3RQNK NkCgb1l5WOypcubPZtqTGlXmhUCmo5uzhcZp5LS9w70c4lQoEqUpMOAoo1QfJSWXxMHpMB 7KAhxeJbnO8+2ErsMHsXR4W3Fd6ndB3CuPabCJnP+ZCy0aAzG9oIXKoLzsRtafkDPC1vMd ULPES0G9ZOGEyzqRamAuBLOCYWVcvw9UbVD1PBpxzp9IJPTtBVGFf3s/oB46+A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="mLG7/geJ"; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Spam-Score: -2.25 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="mLG7/geJ"; dmarc=pass (policy=none) header.from=gmail.com; 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" X-Migadu-Queue-Id: 2ED95FEB1 X-Spam-Score: -2.25 X-Migadu-Scanner: scn1.migadu.com X-TUID: 8al16QDfne1c "Tom Davey" writes: > Hi Tim, > > Thanks for these thoughtful comments. I agree that the Org developers (to > whom I, as a mere user, owe enormous thanks) must be wary before making > changes to how timestamps are handled. > > This argues, I would say, for keeping what I believe was the status quo > since at least Org version 9.4.4: Agenda views would display entries with > active timestamps in property drawers. That has been my historical > experience. > > Tim, has your historical experience been different? In the invoicing example > you give, were the timestamps in the properties drawer active, or inactive? > > I have just verified with a simple test that Org version 9.4.4, which was > shipped with Emacs 27.2 I believe, does display entries with an active > timestamp as the value of a property in the ordinary :PROPERTIES: drawer. > That's the situation I'm calling the "status quo." I'm wondering if my > experience coincides with the experience of others. > > Here's the simple entry that will be shown on the Week/Day Agenda view in > 9.4.4: > > * TODO Test of active timestamps > :PROPERTIES: > :Created: <2022-03-22 Tue 18:30> > :END: > > And note this: adding a second active timestamp to the test entry, e.g., to > accompany a SCHEDULED: keyword, results in the entry appearing on the Agenda > twice, as would be expected: > > * TODO Test of active timestamps > SCHEDULED: <2022-03-22 Tue 18:30> > :PROPERTIES: > :Created: <2022-03-22 Tue 18:30> > :END: > > This second example shows why the variable > org-agenda-skip-additional-timestamps-same-entry is valuable. I rarely want > an entry to display twice on the same day. > For my invoicing system, the timestamps are in property draws, but not under TODO headings, so I guess they wouldn't show up. I have used timestamps in TODO entry property draws, but don't recall seeing them in the agenda when I do. However, I also use a couple of custom agenda views more often than the default agenda view, so I just may not have noticed. Personally, I have no use case for TODOs being displayed in the agenda based on their created date. I do like to log when I created the todo, but would not want to see that cluttering my agenda where I only want to see scheduled and deadline tasks. I use a property draw for this type of information as I consider it metadata about the entry. If I really want ot see the item in the agenda based on a timestamp, then I explicitly add that timestamp to the entry (not in a property draw). In my invoicing module, property draws are used to track invoicing metadata i.e. last invoice number, last invoice date, invoice creation date and invoice period for each invoice, invoice due date, paid datge etc. Some of the timestamps are 'inactive' (they never change) and some are active (will get modified). Perhaps that was a mistake on my part and all of them should be inactive, but at the time, I thought of the distinction as not being purely about whether they show in the agenda, but more about whether they were immutable or not. The need to have another variable to limit the scope of timestamps when you do allow timestamps in property draws makes things feel very 'kludgy'. I get very concerned about all these 'enhancements' we keep adding which then also require additional complexity with multiple variables interacting at different levels. I find the number of variables and complexity associated with the agenda compared to when I first started using org mode to be mind boggling. I often wonder how the maintainers are able to keep on top of the increasing complexity of org mode. What I definitely would NOT want is for TODO tasks in source blocks which have a timestamp associated with them showing up in the agenda. The possible exception might be when the source block is an org source block. What I want in source blocks is for them to behave like a microcosm of the original code environment - I want them to behave exactly as they would when I just edit that code in a code dedicated buffer with the addition of a minimal set of babel/noweb features to allow me to work with code spread over multiple source code blocks etc. I definitely don't want the additional processing overhead of org mode search through my source blocks looking for things which look like they might be timestamps or worse, looking for such things and then trying to do something clever with them (like adding to the agenda). With regards to timestamps in property draws, I'm not sure that arguing the status quo is to keep that behaviour. I'm not sure that behaviour was supposed to work or that it is well defined. It may have worked previously 'by accident' rather than design (something which tends to happen more as complexity increases). For example, what is the situation with timestamps in property draws and inheritance? What is the situation with timestamps and property draws for items which are not TODOs (i.e. normal headings with a property draw)? What happens if I have multiple properties with timestamps as their value? I would agree with Ihor's observation things seem to be inconsistent and we probably need to work at getting things to be more consistent. However, I would lean towards a solution which simplifies the situation in the general case, even if that makes some specialised uses cases more difficult. Given that property draws can have arbitrary property names and some of these could be active timestamps and given there could be multiple properties which have timestamp values in the same property draw and there is supposed to be an inheritance component to properties, I would be inclined to not support adding properties with timestamps to the agenda. If it turns out a lot of people want this functionality, then I would suggest a specific property name be reserved for this i.e. :Agenda-ts: or :Agenda-entry:, rather than allowing any property name with a timestamp. I wouldn't use :Created: as that would be overloading the property to perform two roles (track when an entry was created and add it to the agenda).