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.
next prev parent 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).