emacs-orgmode
[Top][All Lists]
Advanced

[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] :-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]