On Wed, Oct 28, 2015 at 9:52 AM, Nicolas Goaziou wrote:
> cesar mena 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
>> "schedul
cesar mena 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 y
cesar mena 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.
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.
cesar mena 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 be
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
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 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
cesar mena 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 Mo
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 th
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 t
hello guys,
so far so good for me.
thanks nicolas and matt.
-cm
On Sun, Oct 25, 2015 at 1:24 PM, Nicolas Goaziou wrote:
> Nicolas Goaziou writes:
>
>> Matt Lundin writes:
>>
>>> In short, org-habit seems to want a + notation for the purposes of the
>>> agenda display and a .+ notation for th
Nicolas Goaziou writes:
> Matt Lundin 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 opinion
Matt Lundin 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
a427098b57c747ecc76feb0
Nicolas Goaziou writes:
> cesar mena 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
Hello,
cesar mena 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, inclu
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 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
Hello,
cesar mena 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
>
> howeve
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
18 matches
Mail list logo
