From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul R Subject: Re: iCal export of repeated tasks Date: Fri, 13 Jun 2008 11:55:19 +0200 Message-ID: <878wx964mw.fsf@gmail.com> References: <20080610101715.GF5498@atlantic.linksys.moosehall> <20080612100559.GE19396@atlantic.linksys.moosehall> <20080612114705.GG19396@atlantic.linksys.moosehall> <20080613092409.GA8066@atlantic.linksys.moosehall> 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 1K760E-0000fl-C2 for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:55:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K760B-0000eo-P6 for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:55:24 -0400 Received: from [199.232.76.173] (port=36754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K760B-0000el-I1 for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:55:23 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:4903) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K760B-0004UC-4L for emacs-orgmode@gnu.org; Fri, 13 Jun 2008 05:55:23 -0400 Received: by fg-out-1718.google.com with SMTP id l26so3297987fgb.30 for ; Fri, 13 Jun 2008 02:55:21 -0700 (PDT) In-Reply-To: <20080613092409.GA8066@atlantic.linksys.moosehall> (Adam Spiers's message of "Fri\, 13 Jun 2008 10\:24\:09 +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: org-mode mailing list Hi Adam, >> 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. Like Dominik, I consider a repeated event as a calendar object on its own. Such an object has a representation in the iCal format. Org mode must stick to the correct representation of this object, and it is up to each calendar tool to display it in a way or an other to the user. If you consider others tools as broken in this area, and don't feel like fixing them, you can maybe implement a "go-between" layer that takes iCal file in input, and outputs the same iCal file with repeated events changed to dated events, with date set on next occurence. -- Paul