emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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: Tue, 12 Jul 2022 08:20:13 -0300	[thread overview]
Message-ID: <87v8s21nut.fsf@gmail.com> (raw)
In-Reply-To: <87a69f6oa5.fsf@localhost>

Hi Ihor,

On Tue, 12 Jul 2022 at 10:46, Ihor Radchenko <yantar92@gmail.com> 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.


  reply	other threads:[~2022-07-12 13:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29 13:05 [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/)] Gustavo Barros
2021-10-29 13:40 ` Ihor Radchenko
2021-10-29 13:45   ` Gustavo Barros
2022-07-11 13:51   ` Gustavo Barros
2022-07-12  2:46     ` Ihor Radchenko
2022-07-12 11:20       ` Gustavo Barros [this message]
2022-07-18  6:28         ` Ihor Radchenko
2022-07-18 10:30           ` Gustavo Barros

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v8s21nut.fsf@gmail.com \
    --to=gusbrs.2016@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).