From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp11.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 WGt5NjZD1WLcZgAAbAwnHQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Mon, 18 Jul 2022 13:25:42 +0200
Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp11.migadu.com with LMTPS
	id eJ1UNjZD1WKoNwEA9RJhRA
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Mon, 18 Jul 2022 13:25:42 +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 79906C49C
	for <larch@yhetil.org>; Mon, 18 Jul 2022 13:25:42 +0200 (CEST)
Received: from localhost ([::1]:51390 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	id 1oDOsf-0000TQ-M7
	for larch@yhetil.org; Mon, 18 Jul 2022 07:25:41 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:38242)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <gusbrs.2016@gmail.com>)
 id 1oDOsD-0000SI-IR
 for emacs-orgmode@gnu.org; Mon, 18 Jul 2022 07:25:13 -0400
Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]:34341)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <gusbrs.2016@gmail.com>)
 id 1oDOsB-0001Kw-SG
 for emacs-orgmode@gnu.org; Mon, 18 Jul 2022 07:25:13 -0400
Received: by mail-oa1-x33.google.com with SMTP id
 586e51a60fabf-10bffc214ffso22823452fac.1
 for <emacs-orgmode@gnu.org>; Mon, 18 Jul 2022 04:25:09 -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=eJhxMTKRKlAdXjgYluCaaHcT4owp6u/E9vZcRzWeB1I=;
 b=q7ro89ypHU0VyQ8zUrOfZmHvmQ5wyOBJQqQ0gmxkouWwiWlsgkSFim7oO30+FXuj4m
 ezO7T1VSWMgcJ/yvCEvDonR/E4MvJjuD/5sVw3lBH4uo52YTw6zwrmmT/I/Uo18Bi/4U
 PkHANq4BTJMSgn08u0QJ4KQ9CTW7nsCYsPXeN6tFBSjseO8bPoknEIiAgw7bePTKwQ0U
 U+seQkXZ6Du1ZwFath0QGTULzKcTahTQFaiE30mnSbhaTQs8xYSTDn1KCbodeOsDREiT
 KWJG2SzIeRy70SqLRnTZb4mHOv9Vcwr8M8gENVNV+sb6gtYIviFI6r9urNQBuFM861o8
 uLxg==
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=eJhxMTKRKlAdXjgYluCaaHcT4owp6u/E9vZcRzWeB1I=;
 b=CCYfh2Ii9Q54dHUGlSshzC/g8WZBP/8UIiuSidbu4zA42CfM+tNvCj5S2I/cOufdbo
 7FcfRiI+DLblxLJMMeNUAe91Ay0qgwjMvHJc0PE8rd6HFdnleWCmGDvAsCNx2mDW5CSZ
 H245os3/4aasW0IQfIlAQvTjIhQ4dsh197GnrvZ8f3JtaRP8KAwT8DrCm0lrBlFyMC2D
 5yEiSJfezQjm/E/Tc1rRhh4CcJaewVitiHARu8qZOAlw2aUrlxndLWC4HaXetwkpIJwZ
 bEoZY3Os6QuCHSBOqGP7pTLjPLA1RtY7woIjAqbVYyl15wFEnTkQ0gLLw8GnGPRDzhIL
 2kfg==
X-Gm-Message-State: AJIora+Lu3RzGk4F3oZ0XR/DHOP7VVIiOmWj4St0kXmL7SFlCo7jo2Jx
 0IPBoI1R/FWkKA1K4vEBOGvZala73hs=
X-Google-Smtp-Source: AGRyM1tbgHSe1uMwarRyCooVTlUmflhtKTTv/lhnJV+cscCPHGyDUFsKckSe82bkupH1z0wzK9r/6w==
X-Received: by 2002:a05:6808:f89:b0:339:ce78:1ad8 with SMTP id
 o9-20020a0568080f8900b00339ce781ad8mr15824173oiw.207.1658143508676; 
 Mon, 18 Jul 2022 04:25:08 -0700 (PDT)
Received: from gusbrs-laptop ([181.214.227.25])
 by smtp.gmail.com with ESMTPSA id
 2-20020a9d0002000000b0061c24cd628bsm4886248ota.7.2022.07.18.04.25.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 18 Jul 2022 04:25:07 -0700 (PDT)
References: <87ee84dllb.fsf@gmail.com> <87k0hwdk54.fsf@localhost>
 <87tu7n68xs.fsf@gmail.com> <87a69f6oa5.fsf@localhost>
 <87v8s21nut.fsf@gmail.com> <874jzfhr3q.fsf@localhost>
User-agent: mu4e 1.8.6; emacs 28.1
From: Gustavo Barros <gusbrs.2016@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
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: Mon, 18 Jul 2022 07:30:03 -0300
In-reply-to: <874jzfhr3q.fsf@localhost>
Message-ID: <878roqll2u.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Received-SPF: pass client-ip=2001:4860:4864:20::33;
 envelope-from=gusbrs.2016@gmail.com; helo=mail-oa1-x33.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." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: "Emacs-orgmode" <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
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=1658143542;
	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=eJhxMTKRKlAdXjgYluCaaHcT4owp6u/E9vZcRzWeB1I=;
	b=fe6AjXrpokl7/7lHquRN8lb+vjAsg4jplZsHZxIZ/mVvqiLcZd3IUyUenKCpY61I/Rdqg/
	pI+W1iW913BkoBFGqsa+poRc9k28FUCacnym6CFBJba3lXV/0ZCKRXCeA1fwHwdiSSFu9e
	xiZprcRRDT4TO3wTorjM8mIBisjtRGQisAM67l8EAAY0mJVq2jyuRToJW6UOl79w6/IteI
	ZZtWUCTVyBVvlnHIsCY1eKuhmYyF3S98fuqUHaW7UEKhTjJizGUpMGbgabN8ueCFgfnx8Z
	giHIlIoX1x0Bc3U4XUeTLKTdWlhziwnZ5jPbZbJ7EA5fH9tQtUJcI1Hx+Ivu7A==
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1658143542; a=rsa-sha256; cv=none;
	b=kXriB70FRey1lDvzs4ZNirxVfH9To6U3jKZrzF7hzmctTiOZLkHf8Dxg+/fsF/YXTkIVqK
	D7oVbIrkNQahvvvd73GgIxWvLKriGjXCRphKqI+2PsD9TfwhK7EvFSO2EQVJumKOQFkdBg
	MiuSOHlsmBsFIYlPtmwYKWvG4SpD+9gYVOpzWKUmQBL2EmeMuif7Zt/WVvF6mOMwY9sSJ/
	5ejMGhyo5pvThq0a5LQjgxOOC6Ted5kplsDurgATSD99CA27ssaVsHQA6GDzdDX7BXaOIS
	njhZmW3Wu9COCAWHA2WdOiaJ33T7TyRrG6xVFjo2LA3P3CRIEaOpWdXI9N9nOA==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=q7ro89yp;
	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.27
Authentication-Results: aspmx1.migadu.com;
	dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=q7ro89yp;
	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: 79906C49C
X-Spam-Score: 6.27
X-Migadu-Scanner: scn1.migadu.com
X-TUID: gOyWgrT0PLUk

Hi Ihor,

On Mon, 18 Jul 2022 at 14:28, Ihor Radchenko <yantar92@gmail.com> wrote:

> I feel that you are overcomplicating things a bit.

Well, the most important objective of the analysis was to try to figure 
out if the `todayp' condition was too strict or not.  Since your 
suggested fix implies removing it as well, I take I have you convinced? 
;)

> What if we simply change all the agenda lines if and only if their 
> date
> in agenda is earlier or equal to the next scheduled time (after 
> repeater
> is triggered)?

I think this is a good condition, better than the one I had devised 
(considering the span of the agenda and the repetition frequency).  As 
far as I can tell, it will also require parsing the planning info of the 
entry and consider the relevant cases, but perhaps you are seeing more 
than I can.  And I presume you refer only to repeating tasks, so that 
the rest of the current conditional (except `todayp') would remain in 
place.  The only case I can think of which might trip a little this 
condition is a date range, but "date range with repeater" seems corner 
enough for us not to sweat much over it.

One thing to consider is the timing of things and how it affects the 
conditional.  You said "earlier or equal to the next scheduled time 
(after repeater is triggered)".  We are looking at things in 
`org-agenda-todo' after `org-todo' has done its job, in other words, 
after the repeater has "stepped". 
`org-agenda-headline-snapshot-before-repeat' is stored in `org-todo' 
because there would be no longer any way to retrieve it at this point, 
but we don't store anything else, as far as I can tell.  So, at this 
point, the current scheduled (dedlined, etc.) time would be "the 
next/first instance which is *not* done", and hence wouldn't it be 
"earlier, but not equal, to the next scheduled time"?

Another thing for which you might have something in mind, but I don't 
see how to handle it is that `org-agenda-change-all-lines' can receive 
the `just-this' argument and that decides whether just the current line 
gets changed or if all entries with the same marker are looped over.  So 
it's either "this" or "all". Perhaps the version of the conditional you 
suggested will require change in `org-agenda-change-all-lines' so that 
it can change "some, according to a given predicate".

In sum, all in all, the conditional you suggested sounds very good to 
me, and a clear improvement relative to the current state of things. 
And regardless of anything else, it seems we agree that `todayp' is too 
strict and removing it would be the low hanging fruit in all this.

Best,
Gustavo.