From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: iCal export of repeated tasks Date: Fri, 13 Jun 2008 10:24:09 +0100 Message-ID: <20080613092409.GA8066@atlantic.linksys.moosehall> References: <20080610101715.GF5498@atlantic.linksys.moosehall> <20080612100559.GE19396@atlantic.linksys.moosehall> <20080612114705.GG19396@atlantic.linksys.moosehall> Reply-To: Adam Spiers 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 1K75W6-0002c4-5N for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:24:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K75W2-0002bM-OU for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:24:16 -0400 Received: from [199.232.76.173] (port=53100 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K75W1-0002ao-9v for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:24:13 -0400 Received: from mail.beimborn.com ([70.84.38.100]:39699) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K75W0-0000fQ-H4 for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:24:12 -0400 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id m5D9OB4O010494 for ; Fri, 13 Jun 2008 04:24:11 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id m5D9OB4p010489 for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 10:24:11 +0100 Content-Disposition: inline In-Reply-To: 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: org-mode mailing list On Fri, Jun 13, 2008 at 10:18:52AM +0200, Carsten Dominik wrote: > On Jun 12, 2008, at 1:47 PM, Adam Spiers wrote: > >Well, I agree that there may not be a good definition, in which case a > >per-event property disabling export of the RRULE would be a perfect > >solution. > > Hi Adam, > > I do not feel comfortable with this specialized filtering, so I am not > implementing it. It seems incorrect that the export of the exact same > Org file would lead to different iCal files, depending on the day when > you do the export. Sorry - either I have accidentally misled you, or my understanding is missing some nuance of your argument, because it was certainly not my intention to propose a mechanism which would produce different results depending on when the export is done. I simply wanted to suggest that there could be a property which would have the same effect upon iCal export as would manually deleting the directive to repeat ('.+2w' or similar) from the end of the task's timestamp. This would maintain the existing behaviour for repeated tasks within Org, but display it as a non-repeating task in my external calendaring clients (korganizer, ScheduleWorld, Google Calendar, my Nokia phone etc.) The motivation is that while I very much like org's functionality for automatically updating the timestamp on a repeated task once it has been marked as done, I do not want tasks such as "water plants" cluttering up my calendar forever into the future. I only care about the next plant watering, not all others thereafter, and with screen real estate always short in supply (especially on mobile devices!), any possible savings are of value. Actually, now I think about it more, the above decluttering argument applies equally to the Org agenda itself. So if it would be a more consistent request from the point of view of maintaining an intuitive UI or from ease of implementation, I would be perfectly happy if the proposed property disabled display of all but the first instance of the repeated task *everywhere*, i.e. not only in iCal exports, but also in agenda displays. > It seems to be fine for the program displaying the info to do such > filtering - this is what Org does in the agenda. Unfortunately, since the proposed filtering is per-event, with uni-directional export to other clients, the only place it can be done is at the source, i.e. within Org. Otherwise some layering of extra filtering meta-data per-event would be required for each external calendaring client, which would be extremely cumbersome.