org-agenda-scheduled-leaders and repeating tasks

org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hello everyone,

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 patched my version of org to do this (release_8.2.10); but i did it
by not calling org-closest-date in the case of repeating timestamps
with the effect they all act this way. to do this properly i'd imagine
we would need another identifier in the timestamp(?)

i am willing to do the work to contribute the proper patches and
update the doc if people are interested.

... or is there another way of doing this? :)

thank you kindly for reading!

- cesar

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

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

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

Hello,

cesar mena <cmena@pobox.com> writes:

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

I think the previous behaviour was buggy anyway. There is no such thing
as "all occurrences" for special repeaters. There may be any number of
occurrences, including zero, without a predictable pattern.


Regards,

-- 
Nicolas Goaziou

Re: org-agenda-scheduled-leaders and repeating tasks

[Matt Lundin]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> cesar mena <cmena@pobox.com> writes:
>
>> 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.
>

While I agree in principe with this change, I wonder if we could make an
exception for habits. Habits (org-habit.el) customarily use a notation
like this:

--8<---------------cut here---------------start------------->8---
* Go for a run
  :PROPERTIES:
  :STYLE:    habit
  :END:
  <2015-10-16 Fri 16:00 .+1d/2d>
--8<---------------cut here---------------end--------------->8---

This will appear in the agenda with a consistency graph indicating the
last n days of completion (depending on org-habit-preceding-days).
Before the change in commit a427098b57c747ecc76feb0593f32922a1e12f67,
these would appear in my daily agenda at their scheduled time,
regardless of whether I had missed a day or two. Now, if I miss a day,
the habit drops to the bottom of the agenda (it no longer appears at the
scheduled time). IMO, this is undesired behavior; I want to be reminded
of the habit at the same time each day regardless of whether I have done
it on previous days, especially since the consistency graph gives me all
the information I need about past completions.

Changing the timestamp to +1d/2d will is not an option, since the
timestamp only advances one day upon completion. This leads to an
incoherent consistency graph. The graph color remains red, which
indicates incompletion, and the habit stays on the daily agenda, even
though I have just completed it.

In short, org-habit seems to want a + notation for the purposes of the
agenda display and a .+ notation for the purposes of resetting the
timestamp. What is the best solution?

Thanks,
Matt

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

Matt Lundin <mdl@imapmail.org> writes:

> In short, org-habit seems to want a + notation for the purposes of the
> agenda display and a .+ notation for the purposes of resetting the
> timestamp. What is the best solution?

Still looking for it.

Meanwhile, I reverted the opinionated change in
a427098b57c747ecc76feb0593f32922a1e12f67.

Regards,

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Matt Lundin <mdl@imapmail.org> writes:
>
>> In short, org-habit seems to want a + notation for the purposes of the
>> agenda display and a .+ notation for the purposes of resetting the
>> timestamp. What is the best solution?
>
> Still looking for it.
>
> Meanwhile, I reverted the opinionated change in
> a427098b57c747ecc76feb0593f32922a1e12f67.

Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hello guys,

so far so good for me.

thanks nicolas and matt.

-cm

On Sun, Oct 25, 2015 at 1:24 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>
>> Matt Lundin <mdl@imapmail.org> writes:
>>
>>> In short, org-habit seems to want a + notation for the purposes of the
>>> agenda display and a .+ notation for the purposes of resetting the
>>> timestamp. What is the best solution?
>>
>> Still looking for it.
>>
>> Meanwhile, I reverted the opinionated change in
>> a427098b57c747ecc76feb0593f32922a1e12f67.
>
> Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hi again nicolas,

sorry. i made a mistake updating my tree.

i'm quite certain i'm on master now "org-version: 8.3.2
(release_8.3.2-219-g770671)" and the repeater resets itself again.

so presently i have a task that looks like this:

** TODO some task
   SCHEDULED: <2015-08-24 Mon ++1w>

and in the agenda it shows up as:

  Scheduled:  TODO some task

best,
-cm





On Mon, Oct 26, 2015 at 9:13 AM, cesar mena <cmena@pobox.com> wrote:
> hello guys,
>
> so far so good for me.
>
> thanks nicolas and matt.
>
> -cm
>
> On Sun, Oct 25, 2015 at 1:24 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
>> Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:
>>
>>> Matt Lundin <mdl@imapmail.org> writes:
>>>
>>>> In short, org-habit seems to want a + notation for the purposes of the
>>>> agenda display and a .+ notation for the purposes of resetting the
>>>> timestamp. What is the best solution?
>>>
>>> Still looking for it.
>>>
>>> Meanwhile, I reverted the opinionated change in
>>> a427098b57c747ecc76feb0593f32922a1e12f67.
>>
>> Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: org-agenda-scheduled-leaders and repeating tasks

[Samuel Wales]

fwiw, i am one who is so [disorganized?] that the old behavior is
preferred.  if something is a 6m repeater, and i ignore it for 6m,
it's actually useful to be reminded after another repeat.  perhaps
more normal people would understand 1w.  no matter how much i "should"
mootify it or take it off the list or do it, this "bug" has proved
useful in practice.

i don't claim to represent hordes of disorganized people, but there you have it.

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hi samuel,

yes i suspect this is why it hasn't been reported in years.

what say you nicolas?

-cm

On Mon, Oct 26, 2015 at 4:23 PM, Samuel Wales <samologist@gmail.com> wrote:
> fwiw, i am one who is so [disorganized?] that the old behavior is
> preferred.  if something is a 6m repeater, and i ignore it for 6m,
> it's actually useful to be reminded after another repeat.  perhaps
> more normal people would understand 1w.  no matter how much i "should"
> mootify it or take it off the list or do it, this "bug" has proved
> useful in practice.
>
> i don't claim to represent hordes of disorganized people, but there you have it.

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

cesar mena <cmena@pobox.com> writes:
>
> yes i suspect this is why it hasn't been reported in years.
>
> what say you nicolas?

Please do not top-post :)

In any case, I'm not sure Samuel complains about the current behaviour.
Actually, I don't understand what is meant by "the old behaviour" in
this context. The behaviour changed a couple of times already in this
thread.

> On Mon, Oct 26, 2015 at 4:23 PM, Samuel Wales <samologist@gmail.com> wrote:
>> fwiw, i am one who is so [disorganized?] that the old behavior is
>> preferred.  if something is a 6m repeater, and i ignore it for 6m,
>> it's actually useful to be reminded after another repeat.  perhaps
>> more normal people would understand 1w.  no matter how much i "should"
>> mootify it or take it off the list or do it, this "bug" has proved
>> useful in practice.
>>
>> i don't claim to represent hordes of disorganized people, but there you have it.

Regards,

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

cesar mena <cmena@pobox.com> writes:

> sorry. i made a mistake updating my tree.
>
> i'm quite certain i'm on master now "org-version: 8.3.2
> (release_8.3.2-219-g770671)" and the repeater resets itself again.
>
> so presently i have a task that looks like this:
>
> ** TODO some task
>    SCHEDULED: <2015-08-24 Mon ++1w>
>
> and in the agenda it shows up as:
>
>   Scheduled:  TODO some task

Hopefully fixed, this time. Thank you.

Regards,

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

me again :)

the calculation is correct.

however the face is now `org-scheduled-today, as opposed to
`org-scheduled-previously, and the agenda sorting is wrong. instead of
bubbling to the top (since it is so late) it is staying within the
"scheduled today" range.


best,
-cm


On Mon, Oct 26, 2015 at 4:31 PM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> cesar mena <cmena@pobox.com> writes:
>
>> sorry. i made a mistake updating my tree.
>>
>> i'm quite certain i'm on master now "org-version: 8.3.2
>> (release_8.3.2-219-g770671)" and the repeater resets itself again.
>>
>> so presently i have a task that looks like this:
>>
>> ** TODO some task
>>    SCHEDULED: <2015-08-24 Mon ++1w>
>>
>> and in the agenda it shows up as:
>>
>>   Scheduled:  TODO some task
>
> Hopefully fixed, this time. Thank you.
>
> Regards,

Re: org-agenda-scheduled-leaders and repeating tasks

[Samuel Wales]

what i am saying is that the behavior that has existed for many years
for .+ timestamps, is actually useful to me.

same for .+ face, sorting, and so on.

just one data point.

Re: org-agenda-scheduled-leaders and repeating tasks

[Matt Lundin]

cesar mena <cmena@pobox.com> writes:

> me again :)
>
> the calculation is correct.
>
> however the face is now `org-scheduled-today, as opposed to
> `org-scheduled-previously, and the agenda sorting is wrong. instead of
> bubbling to the top (since it is so late) it is staying within the
> "scheduled today" range.

I can confirm that overdue .+ tasks now have the org-scheduled-today
face. It seems like they should have org-scheduled-previously (unless
they are habits, of course).

Matt

Re: org-agenda-scheduled-leaders and repeating tasks

[Nicolas Goaziou]

cesar mena <cmena@pobox.com> writes:

> however the face is now `org-scheduled-today, as opposed to
> `org-scheduled-previously, and the agenda sorting is wrong. instead of
> bubbling to the top (since it is so late) it is staying within the
> "scheduled today" range.

I committed another attempt in master. Thank you.

Regards,

Re: org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

On Wed, Oct 28, 2015 at 9:52 AM, Nicolas Goaziou <mail@nicolasgoaziou.fr> wrote:
> cesar mena <cmena@pobox.com> writes:
>
>> however the face is now `org-scheduled-today, as opposed to
>> `org-scheduled-previously, and the agenda sorting is wrong. instead of
>> bubbling to the top (since it is so late) it is staying within the
>> "scheduled today" range.
>
> I committed another attempt in master. Thank you.
>
> Regards,

hi nicolas, list,

everything works. thank you so much.

nice side-effect: the behaviour now allows one to use non "."
repeaters as a poor man's habit mode since the Sched.x header line
will inform one how many cycles are behind.  it's also much clearer.
before on marking as done, the item will just be automatically
rescheduled again with no feedback as to why.

thanks again.

-cm