From mboxrd@z Thu Jan 1 00:00:00 1970 From: cesar mena Subject: org-agenda-scheduled-leaders and repeating tasks Date: Tue, 13 Oct 2015 18:01:31 -0400 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:40398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm7dV-0000q4-6r for emacs-orgmode@gnu.org; Tue, 13 Oct 2015 18:01:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zm7dU-0007Lt-Du for emacs-orgmode@gnu.org; Tue, 13 Oct 2015 18:01:33 -0400 Received: from mail-ig0-x231.google.com ([2607:f8b0:4001:c05::231]:38580) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zm7dU-0007Lm-9Z for emacs-orgmode@gnu.org; Tue, 13 Oct 2015 18:01:32 -0400 Received: by igsu6 with SMTP id u6so3781446igs.1 for ; Tue, 13 Oct 2015 15:01:31 -0700 (PDT) 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: emacs-orgmode@gnu.org 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