You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let's consider for example this task scheduled today without a time. Org-alert acts like it's scheduled at 15:34 (the timestamp in the oldest clocked time).
*** TODO Laundry
SCHEDULED: <2024-09-19 Thu .+7d>
:LOGBOOK:
- State "DONE" from "TODO" [2024-09-12 Thu 13:53]
CLOCK: [2022-04-29 Fri 23:59]--[2022-04-30 Sat 00:07] => 0:08
- State "STARTED" from "TODO" [2022-04-29 Fri 15:43]
CLOCK: [2022-04-29 Fri 15:30]--[2022-04-29 Fri 15:34] => 0:04
- State "DONE" from "TODO" [2022-03-07 Mon 17:46]
:END:
I tracked the problem to org-alert--parse-entry. It seems that string-match doesn't stop at line boundaries like for example re-search-forward does, so it will match SCHEDULED: < from the scheduling line and 15:34] => from the last clock line.
Probably it would be more robust to change org-alert--parse-entry, but if anybody else has the same problem, removing the first wildcards from org-alert-time-match-string works for me:
Let's consider for example this task scheduled today without a time. Org-alert acts like it's scheduled at 15:34 (the timestamp in the oldest clocked time).
I tracked the problem to
org-alert--parse-entry
. It seems thatstring-match
doesn't stop at line boundaries like for examplere-search-forward
does, so it will matchSCHEDULED: <
from the scheduling line and15:34] =>
from the last clock line.Probably it would be more robust to change
org-alert--parse-entry
, but if anybody else has the same problem, removing the first wildcards fromorg-alert-time-match-string
works for me:The text was updated successfully, but these errors were encountered: