From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Bug: org-time-stamp loses repeater interval Date: Wed, 29 Jun 2011 10:34:02 -0400 Message-ID: <11081.1309358042@alphaville.dokosmarshall.org> References: <2011-06-24T16-30-43@devnull.Karl-Voit.at> <8772.1308931315@alphaville.dokosmarshall.org> <2011-06-26T13-23-38@devnull.Karl-Voit.at> <8739ivw8e8.fsf@gnu.org> <2011-06-28T15-28-18@devnull.Karl-Voit.at> <2011-06-28T18-04-12@devnull.Karl-Voit.at> <87sjqt6f3i.fsf@gnu.org> <2011-06-28T20-40-40@devnull.Karl-Voit.at> <874o39v9td.fsf@gnu.org> <24271.1309302652@alphaville.americas.hpqcorp.net> <87pqlxjyp9.fsf@gnu.org> <5383.1309311845@alphaville.dokosmarshall.org> <80sjqtdrl3.fsf@somewhere.org> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbvqN-0004bG-BJ for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 10:34:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbvqK-0006YW-TC for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 10:34:19 -0400 Received: from vms173005pub.verizon.net ([206.46.173.5]:33920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbvqK-0006YG-Hh for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 10:34:16 -0400 Received: from alphaville.dokosmarshall.org ([unknown] [173.76.32.106]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LNK00GS934QMF10@vms173005.mailsrvcs.net> for emacs-orgmode@gnu.org; Wed, 29 Jun 2011 09:34:08 -0500 (CDT) In-reply-to: Message from "Sebastien Vauban" of "Wed, 29 Jun 2011 09:28:24 +0200." <80sjqtdrl3.fsf@somewhere.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Sebastien Vauban Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org Sebastien Vauban wrote: > Hi Nick, > > Nick Dokos wrote: > > Bastien 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/emacs-orgmode@gnu.org/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] :-)