From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don March Subject: [PATCH] Reschedule "++" repeaters on same day if in future Date: Mon, 27 Jun 2016 02:49:09 -0400 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=001a1145bcf2f923ae05363cebe2 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHQMS-0001Iu-Ky for emacs-orgmode@gnu.org; Mon, 27 Jun 2016 02:49:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bHQMM-0003t8-43 for emacs-orgmode@gnu.org; Mon, 27 Jun 2016 02:49:35 -0400 Received: from mail-it0-f51.google.com ([209.85.214.51]:38194) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bHQML-0003st-Ue for emacs-orgmode@gnu.org; Mon, 27 Jun 2016 02:49:30 -0400 Received: by mail-it0-f51.google.com with SMTP id h190so55732400ith.1 for ; Sun, 26 Jun 2016 23:49:29 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com. [209.85.214.42]) by smtp.gmail.com with ESMTPSA id d126sm1075453iog.20.2016.06.26.23.49.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jun 2016 23:49:28 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id f6so55091764ith.0 for ; Sun, 26 Jun 2016 23:49:28 -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" To: emacs-orgmode@gnu.org --001a1145bcf2f923ae05363cebe2 Content-Type: text/plain; charset=UTF-8 If you have a task with the following timestamp: SCHEDULED: <2016-06-19 Sun 21:00 ++1w> then marking it as DONE at [2016-06-27 at 07:00] should (debatably) result in SCHEDULED: <2016-06-26 Sun 21:00 ++1w> but instead it becomes SCHEDULED: <2016-07-03 Sun 21:00 ++1w> The attached patch changes the behavior to not skip a repeat occurrence that would occur on the day that a task is completed, if there is a time in the timestamp and it is after the current time. This is really useful, at least for me, and also matches a literal reading of the docs. They say (regarding a "++1w" repeater) #+BEGIN_QUOTE Marking this DONE will shift the date by at least one week, but also by as many weeks as it takes to get this date into the future. #+END_QUOTE With a time before the repeater SCHEDULED: <2016-06-19 Sun 21:00 ++1w> you seem to be saying that you don't start working on this task until Sunday evening every week. If you get busy and don't mark it DONE until the next Sunday morning, then you must be talking about the previous instance, not the repeat occurrence which will become available later that day. So it makes sense to increase the timestamp to later that day: SCHEDULED: <2016-06-26 Sun 21:00 ++1w> For another example, suppose you empty the kitchen trash every night: SCHEDULED: <2016-06-19 Sun 22:00 ++1d> If you don't complete that occurrence for two days and then empty the trash on Tuesday morning, you would still want to empty it that night: SCHEDULED: <2016-06-21 Tue 22:00 ++1d> as opposed to skipping Tuesday night and repeating on Wednesday. These examples seem useful to me. But this change could, in theory, lead to the absurd situation of rescheduling a task for just a couple minutes after its completion. But to me that seems the lesser of two evils; you just mark it DONE again, versus the alternative of thinking that you'll be reminded of a task only to forget all about it. If the task is *already* scheduled for later today, this patch does not affect the current behavior--the task will still be rescheduled on the next occurrence on some future day. --001a1145bcf2f923ae05363cebe2 Content-Type: text/x-patch; charset=US-ASCII; name="0001-Reschedule-repeaters-on-same-day-if-in-future.patch" Content-Disposition: attachment; filename="0001-Reschedule-repeaters-on-same-day-if-in-future.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ipxnyd170 RnJvbSA1OTMyOGFhMDA4OWJiMzc2ZGY4NmM4OTEyOGE3NDFhNTlkNDFjMzc4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEb24gTWFyY2ggPGRvbkBvaHNwaXRlLm5ldD4KRGF0ZTogU3Vu LCAyNiBKdW4gMjAxNiAyMzozNTo0NCAtMDcwMApTdWJqZWN0OiBbUEFUQ0hdIFJlc2NoZWR1bGUg IisrIiByZXBlYXRlcnMgb24gc2FtZSBkYXkgaWYgaW4gZnV0dXJlCgoqIGxpc3Avb3JnLmVsIChv cmctYXV0by1yZXBlYXQtbWF5YmUpOiBJbmNsdWRlIGEgdGltZSBpbiBhCiAgdGltZXN0YW1wICho b3VycyBhbmQgbWludXRlcykgd2hlbiBjaGVja2luZyBpZiBhIHJlcGVhdCBvY2N1cnJlbmNlIGlz CiAgaW4gdGhlIGZ1dHVyZS4KLS0tCiBsaXNwL29yZy5lbCB8IDQgKystLQogMSBmaWxlIGNoYW5n ZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL29y Zy5lbCBiL2xpc3Avb3JnLmVsCmluZGV4IGUxM2U4MmQuLjBiMTAyZmIgMTAwNjQ0Ci0tLSBhL2xp c3Avb3JnLmVsCisrKyBiL2xpc3Avb3JnLmVsCkBAIC0xMzI4Nyw4ICsxMzI4Nyw4IEBAIGhhcyBi ZWVuIHNldCIKIAkJCShsZXQgKChuc2hpZnRtYXggMTApCiAJCQkgICAgICAobnNoaWZ0IDApKQog CQkJICAod2hpbGUgKG9yICg9IG5zaGlmdCAwKQotCQkJCSAgICAgKDw9ICh0aW1lLXRvLWRheXMg dGltZSkKLQkJCQkJICh0aW1lLXRvLWRheXMgKGN1cnJlbnQtdGltZSkpKSkKKwkJCQkgICAgIChv ciAodGltZS1sZXNzLXAgdGltZSAoY3VycmVudC10aW1lKSkKKwkJCQkJIChlcXVhbCB0aW1lIChj dXJyZW50LXRpbWUpKSkpCiAJCQkgICAgKHdoZW4gKD0gKGNsLWluY2YgbnNoaWZ0KSBuc2hpZnRt YXgpCiAJCQkgICAgICAob3IgKHktb3Itbi1wCiAJCQkJICAgKGZvcm1hdCAiJWQgcmVwZWF0ZXIg aW50ZXJ2YWxzIHdlcmUgbm90IFwKLS0gCjIuOC4xCgo= --001a1145bcf2f923ae05363cebe2--