[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Bug: org-time-stamp loses repeater interval
From: |
Nick Dokos |
Subject: |
Re: [O] Bug: org-time-stamp loses repeater interval |
Date: |
Wed, 29 Jun 2011 10:34:02 -0400 |
Sebastien Vauban <address@hidden> wrote:
> Hi Nick,
>
> Nick Dokos wrote:
> > Bastien <address@hidden> wrote:
> >> Okay, I've pushed another fix.
> >>
> >> This let me stumble upon another case: the one with org-schedule and
> >> org-deadline ignoring warning cookies -- these cases are also fixed.
> >>
> >> Please confirm!
> >
> > Confirmed. There is a peculiar corner case:
> >
> > If I have a headline that's both scheduled and deadlined, like this:
> >
> > * scheduled
> > DEADLINE: <2011-07-04 Mon +2w -3d>
> > SCHEDULED: <2011-07-06 Wed +1w -2d>
> >
> > and I C-c C-s in the scheduled date, I get a second SCHEDULED: item
> > with the new date on the DEADLINE line. The original SCHEDULED: is
> > still on the next line, unchanged - like this:
> >
> > * scheduled
> > DEADLINE: <2011-07-04 Mon +2w -3d> SCHEDULED: <2011-07-03 Sun +1w -2d>
> > SCHEDULED: <2011-07-06 Wed +1w -2d>
>
> See http://www.mail-archive.com/address@hidden/msg37987.html where I
> report such a case with inactive timestamps and SCHEDULED dates.
>
> See Bastien's answer in the same thread. In this case, SCHEDULED should come
> first, before DEADLINE, for it to work.
>
> Note -- I prefer that order (SCHEDULED, then DEADLINE) since dates are then
> chronologically sorted (at least, I expect so, that SCHEDULED date < DEADLINE
> date)...
>
Seb,
thanks for pointing out the thread. I think Bastien is referring to the
order of {SCHEDULED or DEADLINE} against inactive, so it's not quite the
same - in particular, he mentions that he uses SCHEDULED and DEADLINE
together, but I cannot see a dictum about which one of those should come
first.
For my part, my needs are simple: I never have more than one timestamp
on an item, so I don't run into these corner cases usually (except when
I'm in twisted testing mode). And the existence of these corner cases
validates my approach[fn:1].
It would theoretically be better if there were no rules of course: you
could put any set of timestamps in any order you liked and org would do
the right thing in all cases. But I doubt very much that the effort is
worth it. If there are hard-and-fast rules, about ordering however, an
addition to the docs might be a good idea (unless it's already there -
I haven't checked).
The other thing that I *think* I ran into is that occasionally, with a
DEADLINE and SCHEDULED on the same line, changing one would change the
*order*. I did wonder whether org was chronologically ordering them, but
that was not the case. However, I cannot duplicate the reordering at all
now (I tried quite a few times), so I could have imagined it (after all,
it happened yesterday, which was a red-letter day of imaginary findings
for me).
Thanks,
Nick
Footnotes:
[fn:1] :-)
- Re: [O] Bug: org-time-stamp loses repeater interval, (continued)
- Re: [O] Bug: org-time-stamp loses repeater interval, Bastien, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Karl Voit, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Bastien, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Karl Voit, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Bastien, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Nick Dokos, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Bastien, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Nick Dokos, 2011/06/28
- Re: [O] Bug: org-time-stamp loses repeater interval, Sebastien Vauban, 2011/06/29
- Re: [O] Bug: org-time-stamp loses repeater interval, Bastien, 2011/06/29
- Re: [O] Bug: org-time-stamp loses repeater interval,
Nick Dokos <=
- Re: [O] Bug: org-time-stamp loses repeater interval, Karl Voit, 2011/06/29
Re: [O] org-time-stamp loses repeater interval, Bernt Hansen, 2011/06/24