From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Lundin Subject: Re: Cannot reschedule task with repeater Date: Mon, 08 Mar 2010 20:57:47 -0500 Message-ID: <873a0a2r50.fsf@fastmail.fm> References: <08CB54C5-C25E-4128-9F36-4319CA9D1BFD@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NoohG-0003Qz-O9 for emacs-orgmode@gnu.org; Mon, 08 Mar 2010 20:57:22 -0500 Received: from [140.186.70.92] (port=34870 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NoohF-0003Qr-P5 for emacs-orgmode@gnu.org; Mon, 08 Mar 2010 20:57:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NoohE-0000Rs-Dc for emacs-orgmode@gnu.org; Mon, 08 Mar 2010 20:57:21 -0500 Received: from out1.smtp.messagingengine.com ([66.111.4.25]:54323) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NoohE-0000RZ-AX for emacs-orgmode@gnu.org; Mon, 08 Mar 2010 20:57:20 -0500 In-Reply-To: <08CB54C5-C25E-4128-9F36-4319CA9D1BFD@gmail.com> (Carsten Dominik's message of "Mon, 8 Mar 2010 18:18:33 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: Tom , emacs-orgmode@gnu.org Carsten Dominik writes: > On Mar 8, 2010, at 8:57 AM, Tom wrote: > >> It's not clear to me in case of a timestamp like this >> >> <2010-03-08 H 21:30 .+1d> >> >> why can't the reschedule feature change the date/time part only >> and leave the repeater part intact? Why does it have to throw the >> error "Cannot reschedule task with repeater"? >> >> I see no compelling reason for not allowing rescheduling in this case. >> Maybe an option could be added which the user could set if he wants >> to allow rescheduling even in case of schedules with repeater. > > Hi Tom, > > there is no compelling reason except a technical reason. It was > kind of hard to make this work because of the way scheduling > and deadlining is implemented. When I added the error message, > it was because that seemed better than removing the repeater silently. > > I have now removed this limitation, because, as you say, it > really should not be there.D This is wonderful news! I've been wishing for this functionality for a long time. Thanks to Tom for asking and thanks to Carsten, as always, for implementing it. Best, Matt