From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id AOc6JMd2zWJ8dAAAbAwnHQ (envelope-from ) for ; Tue, 12 Jul 2022 15:27:35 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id +OIzI8d2zWJbIgAAG6o9tA (envelope-from ) for ; Tue, 12 Jul 2022 15:27:35 +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 292E32ABC for ; Tue, 12 Jul 2022 15:27:35 +0200 (CEST) Received: from localhost ([::1]:54198 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBFvK-0000eT-7F for larch@yhetil.org; Tue, 12 Jul 2022 09:27:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59838) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBFbf-0001Mx-3Z for emacs-orgmode@gnu.org; Tue, 12 Jul 2022 09:07:15 -0400 Received: from mail-oa1-x2d.google.com ([2001:4860:4864:20::2d]:42690) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oBFbd-00041j-0H for emacs-orgmode@gnu.org; Tue, 12 Jul 2022 09:07:14 -0400 Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-f2a4c51c45so10209683fac.9 for ; Tue, 12 Jul 2022 06:07:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=sQnA5glnByZsY4nUN+zoRuO7j5JZ7YxXDLh/T+SDFKA=; b=cQIJl59tYfQkR2+v5WGLEEGw+EGn5cN12wD3l0iqCQsGofArNyNEUBqVbp4Vv5o4A0 cgqhC67PDiHCYd4iMBYLAIsLERJfKlGnR90mfMLeMyFzVaq8LDgn6rQQclbATN/W14me dmwhJhLiz0lg2WPuR0LkTrJb/ivEfnwgNp6/qYFQTAtD1mCW8BE+NCW11wHirBeZf6eR t8T2FoTK/68MBAWSvMNsnnJdOPdyDpJSzD+pyqluJBCCgUsvYdPZlnMRDnfHguUwtoK/ ydp4qE0ivlNrKEdQv5B8eThgPHkjdyWPhAgahOHSAPizk/HemC2yVVa2+ZHls0FRENkI DhZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:references:user-agent:from:to:cc:subject :date:in-reply-to:message-id:mime-version; bh=sQnA5glnByZsY4nUN+zoRuO7j5JZ7YxXDLh/T+SDFKA=; b=fSzgp/OwqJ+6a9Uq1Do4ed0X7g4bjuvDvEkUiAfWeLOrpwkTCWed/lKXUEIPur2Hdx RbcDTTYOoG89v2nP7fpzzQaA4sIQyU12IaOeyoLYttVPDiGO+nUE9n/pfRgTcOGAPHyg VFbWcnx9XwZO8rG/HGpnFnQpW6KH4lDZWM2IkT3UrBBD6YQMh/oLg9Q+WPh+klCCHdY6 QLgKAJQPJw91Vg4jjfp3FTm57p0nkPz07L195EhKNTXXcftOSoxX2VYw/CTDHjYkicvl cMDPkL1iw0tbX+xwdfFkuGhYiIrzzijfJNqcOvZaKC6eSNSsDZ5d7ZnHjBmzJm94IqvH BF5w== X-Gm-Message-State: AJIora9EC96P2OlXPjo99Gp+hVuehgkSdnqtPwsoGkE2o526XzJ6e+8g /y+m/1JCgmgZwcJclJGaKQvY1DCw0ag/Ig== X-Google-Smtp-Source: AGRyM1vT8pGnxbL86492DEkYBxpOHu7f0929VvvQKtYWqw58RR/kBpzK0iIVbghvySUEj+zooHJKtg== X-Received: by 2002:a05:6870:c186:b0:101:f97d:eff4 with SMTP id h6-20020a056870c18600b00101f97deff4mr1652070oad.289.1657631231179; Tue, 12 Jul 2022 06:07:11 -0700 (PDT) Received: from gusbrs-laptop ([154.29.131.150]) by smtp.gmail.com with ESMTPSA id w65-20020aca6244000000b00325cda1ff99sm3930174oib.24.2022.07.12.06.07.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 06:07:10 -0700 (PDT) References: <87ee84dllb.fsf@gmail.com> <87k0hwdk54.fsf@localhost> <87tu7n68xs.fsf@gmail.com> <87a69f6oa5.fsf@localhost> User-agent: mu4e 1.8.5; emacs 28.1 From: Gustavo Barros To: Ihor Radchenko Cc: emacs-orgmode@gnu.org Subject: Re: [BUG] Future repeated tasks marked done in Org Agenda don't show as done [9.5 (9.5-g0a86ad @ /home/gustavo/.emacs.d/elpa/org-9.5/)] Date: Tue, 12 Jul 2022 08:20:13 -0300 In-reply-to: <87a69f6oa5.fsf@localhost> Message-ID: <87v8s21nut.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=2001:4860:4864:20::2d; envelope-from=gusbrs.2016@gmail.com; helo=mail-oa1-x2d.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" 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=1657632455; 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=sQnA5glnByZsY4nUN+zoRuO7j5JZ7YxXDLh/T+SDFKA=; b=sgIHqjGJezc0MhZnieR1N6WunZ97kImDNbwOuRekd68uDgH4q+TYyjM9fXOCYxsDCijG3Q 5cXU6UZQ4RUgTkE4A7wc5al7PKzPFBlscjYNEsO1ww/Gdrg01sIBljbj+7bPOWqAvVTi/g R6Pav1KZlwyIkzQ7NaWC1TaF37Zk13Aj/WqrFLEWo1CgmIeo7oIah4BAehyv17HJ17EO3s PrpRCM4PPUIWkOmdKBnzT/OxhHugwhCRNdlkWRiGTPiag40yOWC47OgcI0AHaEZXNYbPzX chMvvfqv8R+/ppMpezB53Cu0/NG3pD3cWpIPrmJLU0Ly+lh4+jvUxHP8afHANg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1657632455; a=rsa-sha256; cv=none; b=VYF43YhBcDhwJ19HBOPWbbqKcudlG8L2uv6b3PRaVNLOjbvjrkwctMQxmnHsMftaCZHyOi PFQRFV0NN380jIUIBcFOaWqq/p96Fd5/nfGcqRqVMdAkSZMTskzpZvstvIbD3m/kmSBWZY CUamDp/uSCXui1W1e9uX4QFonQg/Gf/5HvQ9v1ARHY+qXL0vkNRRG1/CqBdt9rhPtIPcE7 bGHLHzaRihG+TGcR2rQGCH8Z9vVXfwinoXb+qIe4VLlFkX+yVhvY/0A4cPE50d+Vbrm3gO lCusE/GHljOqRvveQeqNwHqd6re//AxiEleCzpdno23j4L9elhWV9t8H5ebFUg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=cQIJl59t; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 6.25 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=cQIJl59t; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: 292E32ABC X-Spam-Score: 6.25 X-Migadu-Scanner: scn1.migadu.com X-TUID: 2pxpL4c9Kpvi Hi Ihor, On Tue, 12 Jul 2022 at 10:46, Ihor Radchenko wrote: > Thanks for the detailed analysis! I thank you again for your continued interest in this little report. > I dug through the old commits and found where this behaviour has been > introduced: > > Commit 0bbf3a9bd message details the current behaviour and its > caveats: Ah! this definetely clears up the intended purpose of the condition. Great dig! > As you can see, the todayp condition is avoiding issues with weekly > agenda when the same habit is displayed multiple times. > > The problem you observed is also noted and left unresolved. > > Ideas how to deal with the described are welcome! I can try to think this trough with you, if you'd like. Since I'm the reporter and bumper, it is fair that I start and try to build a base for it. The TL;DR for what follows is that I think `todayp' is ultimately the "wrong" condition to apply, but is a good *proxy*. Perhaps there's a chance to get to a more correct condition, but I'm not sure. But, even if not, I'd like to argue that the "occurrence at point" may be a better proxy, which would be the condition applied (as far as I can tell, which see) if the `todayp' condition were dropped. The long version: First a preliminary observation. I think the case "noted and left unresolved" in the commit message is somewhat different than the one reported here. Related, of course, but different. Let's consider a hypothetical agenda with the following characteristics: a weekly agenda starting on Monday (fixed), today is Tuesday. Unless stated otherwise, this is the scenario for the examples that follow. A daily repeating task, scheduled for today will appear in the agenda from Tuesday to Sunday. If we move point to the occurrence of that task on, say, Thursday, and mark it done then, we would have the case described in the commit message. I'm not sure it is "unlikely", but we could argue that this is "dubious user input". Now consider the case of a weekly repeating task scheduled for Thursday. This is the case reported here. And I think marking this entry done "ahead of schedule" is arguably more legitimate user input. For once, this entry only appears once in the given agenda view, there is no option to use any other. That said, let's try to be systematic. There are a number of reasons an entry may appear multiple times in an agenda view: A1) The entry is scheduled in a past date, and this past date is also visible in the agenda view. In the example agenda a task scheduled for Monday would appear both Monday, and today, Tuesday. A2) The entry has a deadline in a future date, this future date is visible in the agenda view, and the deadline warning settings are enough to be shown today as well. A task with a deadline for Thursday would appear today, Tuesday, and Thursday. B) The entry is scheduled (deadlined?) to a range of dates. For example, a task scheduled to a range from Thursday to Saturday this week would appear four times in the agenda view, once for the regular schedule and thrice for the range "(N/3)". C) The entry has a repeater whose frequency is higher than the span of the agenda view. A daily task on a weekly view, a weekly task on a monthly view, etc. Of course, a given entry may appear in the agenda multiple times for multiple of these reasons. That's all I can think of. Do you see any other cases? This is a critical question, because the soundness of the argument depends on this list being exhaustive. Anyway, pending on that, let me go on. Now, this bug only affects repeating tasks, because the problem arises only for them because their state in the underlying buffer does not correspond to the "todo change the user has just applied". Indeed, `org-agenda-headline-snapshot-before-repeat' is correspondingly just stored for them, as the name implies. Furthermore, reasons A1, A2 and B, are not specific to repeating tasks, though they affect them too, of course. Reason C is the only one specific to repeating tasks, and is really the only reason I think grants for the case considered in the commit message: >> Because the same line may be present in >> other lines in the same weekly agenda, we cannot simply update all >> lines related to this entry. Indeed, a non-repeating task which appears multiple times in the agenda view (A1, A2, or B), when marked done, is visually changed as such in all occurrences. The same does not happen for a repeating entry because, well, "there might be C (as well?)...". That's the nature of the problem, as far as I can see. And a real one at that. I don't know enough of the agenda machinery to know if among the metadata stored as text properties we would be able to distinguish "C" from the other reasons for a given occurrence of a given entry. It is probably fair to presume it is not possible to distinguish, otherwise Carsten might have leveraged that information. That given, `todayp' does get us a good approximation of the case which appears to have been focused in the commit: a daily task on a weekly agenda view. However, it fails to get any occurrence in the case reported here: a weekly task on a weekly agenda scheduled in the future and marked done ahead of schedule. This discussion was enough for me to conceive another failing case: a weekly task scheduled in the past, and marked done in the past occurrence (say the task scheduled to yesterday, Monday, will be visually marked correctly if marked done in the today occurrence, but not in this is done from the past one). Some ways which could improve things. First, we could rule out the "C" case for repeated entries whose repeating frequency is not higher than the span of the agenda view. We know that an entry with a weekly repeater will not appear more than once in a weekly agenda view. Well, at least not for reason "C", it may appear multiple times for other reasons, in which case it is not a problem, and we can apply the state change to all occurrences, as is done for a similar entry which does not repeat (that, is visually mark all occurrences with the new state). (The frequency may have to be stored for that, but it is likely viable and not too complicated, in practice as long as we can distinguish the case, we could not set `just-one' to `t' for it). Second, we may wish to choose a better proxy for the remainder cases. One could argue for the "first occurrence" or "the occurrence at point". Actually, the current state of things is "the occurrence at point, if today". I've argued above that there exist cases when the `todayp' condition fails to catch the intended case. It is also a double condition trying to exclude visual state change of "unintended cases". `todayp' is not even sufficient to ensure correctness of the case in focus at the commit message ("correctness" here meaning a precise correspondence between the operation visualized in the agenda and the operation actually carried out in the underlying buffer). Suppose, for example, a daily repeating task on a weekly view ("+1d" repeater), but which is a day late. In our example agenda, scheduled for Monday. It appears every day in our weekly view. If we go to today and mark the task done, it will be visually marked as such. But it was actually marked done "yesterday", and if we now refresh the agenda, the task is back today as scheduled (and correctly so). But, if the user asked an entry to be marked as done at a certain point in the agenda buffer, is it really so bad to visually mark the occurrence at point (regardless of whether it is in today's date), even if the operation in the underlying buffer happened in a different day? In other words, why not drop the `todayp' condition? If I read the code correctly, the `just-one' argument passed to `org-agenda-change-all-lines' already restricts the visual change to the occurrence at point. WDYT? Best, Gustavo.