iCal export of repeated tasks

iCal export of repeated tasks

[Adam Spiers]

Currently, if I have a repeated task such as 

* NEXT [#B] water plants
  SCHEDULED: <2008-06-16 Mon 10:30-10:45 .+1w> 

then iCal export includes something like this in the VEVENT:

RRULE:FREQ=WEEKLY;INTERVAL=1

For most repeated tasks, this is a perfectly sensible default.
However, for a task of this nature, I only want to see the next
occurrence show up in my calendar client - any more just clutters up
the monthly view.  So I would suggest that there should be an option
to control whether the repeated occurrences get exported.  Even better
if you could limit this to only apply to certain types of repeat;
maybe having it only apply to the 'battery charging' type of renewable
events denoted by '.+' would make a sensible default?

Re: iCal export of repeated tasks

[Carsten Dominik]

I don't think the icalendar format does support repeated entries for a  
limited time interval, does it?

- Carsten

On Jun 10, 2008, at 12:17 PM, Adam Spiers wrote:

> Currently, if I have a repeated task such as
>
> * NEXT [#B] water plants
>  SCHEDULED: <2008-06-16 Mon 10:30-10:45 .+1w>
>
> then iCal export includes something like this in the VEVENT:
>
> RRULE:FREQ=WEEKLY;INTERVAL=1
>
> For most repeated tasks, this is a perfectly sensible default.
> However, for a task of this nature, I only want to see the next
> occurrence show up in my calendar client - any more just clutters up
> the monthly view.  So I would suggest that there should be an option
> to control whether the repeated occurrences get exported.  Even better
> if you could limit this to only apply to certain types of repeat;
> maybe having it only apply to the 'battery charging' type of renewable
> events denoted by '.+' would make a sensible default?
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: iCal export of repeated tasks

[Adam Spiers]

On Thu, Jun 12, 2008 at 08:02:48AM +0200, Carsten Dominik wrote:
> On Jun 10, 2008, at 12:17 PM, Adam Spiers wrote:
> 
> >Currently, if I have a repeated task such as
> >
> >* NEXT [#B] water plants
> > SCHEDULED: <2008-06-16 Mon 10:30-10:45 .+1w>
> >
> >then iCal export includes something like this in the VEVENT:
> >
> >RRULE:FREQ=WEEKLY;INTERVAL=1
> >
> >For most repeated tasks, this is a perfectly sensible default.
> >However, for a task of this nature, I only want to see the next
> >occurrence show up in my calendar client - any more just clutters up
> >the monthly view.  So I would suggest that there should be an option
> >to control whether the repeated occurrences get exported.  Even better
> >if you could limit this to only apply to certain types of repeat;
> >maybe having it only apply to the 'battery charging' type of renewable
> >events denoted by '.+' would make a sensible default?
>
> I don't think the icalendar format does support repeated entries for a  
> limited time interval, does it?

Quite possibly not - however this need not get in the way of my
suggestion, which was simply to export the repeated event as a one-off
where appropriate.  Does that make sense?

Re: iCal export of repeated tasks

[Carsten Dominik]

On Jun 12, 2008, at 12:05 PM, Adam Spiers wrote:

> On Thu, Jun 12, 2008 at 08:02:48AM +0200, Carsten Dominik wrote:
>> On Jun 10, 2008, at 12:17 PM, Adam Spiers wrote:
>>
>>> Currently, if I have a repeated task such as
>>>
>>> * NEXT [#B] water plants
>>> SCHEDULED: <2008-06-16 Mon 10:30-10:45 .+1w>
>>>
>>> then iCal export includes something like this in the VEVENT:
>>>
>>> RRULE:FREQ=WEEKLY;INTERVAL=1
>>>
>>> For most repeated tasks, this is a perfectly sensible default.
>>> However, for a task of this nature, I only want to see the next
>>> occurrence show up in my calendar client - any more just clutters up
>>> the monthly view.  So I would suggest that there should be an option
>>> to control whether the repeated occurrences get exported.  Even  
>>> better
>>> if you could limit this to only apply to certain types of repeat;
>>> maybe having it only apply to the 'battery charging' type of  
>>> renewable
>>> events denoted by '.+' would make a sensible default?
>>
>> I don't think the icalendar format does support repeated entries  
>> for a
>> limited time interval, does it?
>
> Quite possibly not - however this need not get in the way of my
> suggestion, which was simply to export the repeated event as a one-off
> where appropriate.  Does that make sense?

Not really, to be honest.  I am having trouble to envision a good  
definitions of when a repeated event is a repeated one and when not.

- Carsten

Re: iCal export of repeated tasks

[Adam Spiers]

On Thu, Jun 12, 2008 at 12:54:04PM +0200, Carsten Dominik wrote:
> On Jun 12, 2008, at 12:05 PM, Adam Spiers wrote:
> >On Thu, Jun 12, 2008 at 08:02:48AM +0200, Carsten Dominik wrote:
> >>On Jun 10, 2008, at 12:17 PM, Adam Spiers wrote:
> >>
> >>>Currently, if I have a repeated task such as
> >>>
> >>>* NEXT [#B] water plants
> >>>SCHEDULED: <2008-06-16 Mon 10:30-10:45 .+1w>
> >>>
> >>>then iCal export includes something like this in the VEVENT:
> >>>
> >>>RRULE:FREQ=WEEKLY;INTERVAL=1
> >>>
> >>>For most repeated tasks, this is a perfectly sensible default.
> >>>However, for a task of this nature, I only want to see the next
> >>>occurrence show up in my calendar client - any more just clutters
> >>>up the monthly view.  So I would suggest that there should be an
> >>>option to control whether the repeated occurrences get exported.
> >>>Even better if you could limit this to only apply to certain
> >>>types of repeat; maybe having it only apply to the 'battery
> >>>charging' type of renewable events denoted by '.+' would make a
> >>>sensible default?
> >>
> >>I don't think the icalendar format does support repeated entries
> >>for a limited time interval, does it?
> >
> >Quite possibly not - however this need not get in the way of my
> >suggestion, which was simply to export the repeated event as a one-off
> >where appropriate.  Does that make sense?
> 
> Not really, to be honest.  I am having trouble to envision a good  
> definitions of when a repeated event is a repeated one and when not.

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.

Re: iCal export of repeated tasks

[Carsten Dominik]

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.  It seems to be fine for the program displaying the  
info to do such filtering - this is what Org does in the agenda.

- Carsten

Re: iCal export of repeated tasks

[Adam Spiers]

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.

Re: iCal export of repeated tasks

[Paul R]

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

Re: Re: iCal export of repeated tasks

[Adam Spiers]

On Fri, Jun 13, 2008 at 11:55:19AM +0200, Paul R wrote:
> 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.

In that case correctness in this context is evidently rather
subjective.

Ultimately, the tools are there to serve their masters, and the iCal
format is simply a medium for communicating user data between
end-points in a standard interoperable fashion.  It is up to the users
to determine what data actually needs to be communicated via the
format.  In my case, if I should explicitly request the tool to hide
the repetition of events in order to avoid cluttering my display, I
see nothing incorrect about the tool doing just that.  Likewise, as
another hypothetical example, if all my events had LOCATION
properties, it would be equally valid and correct to export them to
one iCal file for use with korganizer on a full desktop display, and
to another iCal file with the LOCATION properties trimmed out to save
space on a mobile phone display.

> If you consider others tools as broken in this area,

No I do not.

In any case, I will use the hook which Carsten kindly provided.

Re: iCal export of repeated tasks

[Paul R]

Adam Spiers <orgmode@adamspiers.org> writes:

>                                                Likewise, as
> another hypothetical example, if all my events had LOCATION
> properties, it would be equally valid and correct to export them to
> one iCal file for use with korganizer on a full desktop display, and
> to another iCal file with the LOCATION properties trimmed out to save
> space on a mobile phone display.

This is a good use-case, and once again, I consider org export should
provide full information, and later a convert tools should
degrade/adapt it to the target software or device. Implementing such a
processing in every calendaring tools would be a massive duplication.
The "iCal to iCal" converter is the way to go, IMO.

-- 
      Paul

Re: Re: iCal export of repeated tasks

[Adam Spiers]

On Fri, Jun 13, 2008 at 11:55:19AM +0200, Paul R wrote:
> [...] 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.

On Fri, Jun 13, 2008 at 02:56:09PM +0200, Paul R wrote:
> This is a good use-case, and once again, I consider org export should
> provide full information, and later a convert tools should
> degrade/adapt it to the target software or device. Implementing such a
> processing in every calendaring tools would be a massive duplication.
> The "iCal to iCal" converter is the way to go, IMO.

I see your point.  The main disadvantage is that it doesn't work if
you want to apply the filter to the view in the client which
originally generated the iCal from the "master" event data (in our
case, org-mode) - you'd have to export it, pass it through the filter,
then reimport it ...

Re: iCal export of repeated tasks

[Carsten Dominik]

On Jun 13, 2008, at 11:24 AM, Adam Spiers wrote:

> 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.

I can see that this is useful, but I still insist that Org should  
export a repeated event as such.   I am adding a hook, `org-before- 
save-iCalendar-file-hook'.  You can add some special cookie in the  
headline of the entry, and then search for this cookie in the exported  
file and remove the repetition rule.  How about that?

> 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.

Org has the variable `org-agenda-repeating-timestamp-show-all' which  
allows
to modify this behavior for all repeating time stamps, not for  
individual ones, though.


- Carsten

Re: iCal export of repeated tasks

[Adam Spiers]

On Fri, Jun 13, 2008 at 12:28:48PM +0200, Carsten Dominik wrote:
> On Jun 13, 2008, at 11:24 AM, Adam Spiers wrote:
> >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.
> 
> I can see that this is useful, but I still insist that Org should  
> export a repeated event as such.

As the *default* behaviour, without another behaviour being very
specifically requested by the user, I entirely agree :-)

> I am adding a hook, `org-before-save-iCalendar-file-hook'.  You can
> add some special cookie in the headline of the entry, and then
> search for this cookie in the exported file and remove the
> repetition rule.  How about that?

Yes thanks; that should do it, and will also possibly enable other use
cases via that hook.

> >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.
> 
> Org has the variable `org-agenda-repeating-timestamp-show-all' which
> allows to modify this behavior for all repeating time stamps, not
> for individual ones, though.

Well, perhaps you might consider it at some point in the future, or at
least a distinction between repeated events and repeated tasks.
I think we've now spent enough energy on this relatively minor
cosmetic issue though ;-)