Hi Nicolas,

Thanks!  Your approach works for me, buy won't it trip up someone who is
used to the current behaviour?

Cheers
-cm
Hello,

cesar mena <cmena@pobox.com> writes:

> i think what i am trying to say is best shown with an example.
>
> so let's say that today is oct 13th.
>
> the task
> ** TODO check smoke alarm
>    SCHEDULED: <2015-10-04 Sun .+10d>
>
> shows up in the agenda as:
>
>     Sched.10x:  TODO check smoke alarm
>
> however, had the task been scheduled a day before (or if today was oct
14th):
>
>  ** TODO check smoke alarm
>    SCHEDULED: <2015-10-03 Sat .+10d>
>
> it would show up in the agenda as:
>
>     Scheduled:  TODO check smoke alarm
>
> that is to say, the marker that indicates it is overdue is gone.  for
> some cases, like checking the smoke alarm, i don't want the "Sched.?x"
> to reset.
>
>     ie, Sched.11x:  TODO check smoke alarm
>
> i tracked this down to the function org-time-string-to-absolute.  when
> rendering the agenda it gets called with today as its DAYNR argument,
> which causes "org-closest-date" to return "today" for the case of
> repeating timestamps.
>
> i can understand why it is done this way, and i find it useful.
> however for some tasks, i'd rather the counter not reset lest i miss
> something for longer than i should have (the smoke alarm case for
> example).

I fixed the issue with a rather opinionated change.
`org-agenda-repeating-timestamp-show-all' no longer applies on ".+" and
"++" repeaters.

Thank you.


Regards,

--
Nicolas Goaziou