* iCal export of repeated tasks
@ 2008-06-10 10:17 Adam Spiers
2008-06-12 6:02 ` Carsten Dominik
0 siblings, 1 reply; 13+ messages in thread
From: Adam Spiers @ 2008-06-10 10:17 UTC (permalink / raw)
To: org-mode mailing list
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-10 10:17 iCal export of repeated tasks Adam Spiers
@ 2008-06-12 6:02 ` Carsten Dominik
2008-06-12 10:05 ` Adam Spiers
0 siblings, 1 reply; 13+ messages in thread
From: Carsten Dominik @ 2008-06-12 6:02 UTC (permalink / raw)
To: Adam Spiers; +Cc: org-mode mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-12 6:02 ` Carsten Dominik
@ 2008-06-12 10:05 ` Adam Spiers
2008-06-12 10:54 ` Carsten Dominik
0 siblings, 1 reply; 13+ messages in thread
From: Adam Spiers @ 2008-06-12 10:05 UTC (permalink / raw)
To: org-mode mailing list
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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-12 10:05 ` Adam Spiers
@ 2008-06-12 10:54 ` Carsten Dominik
2008-06-12 11:47 ` Adam Spiers
0 siblings, 1 reply; 13+ messages in thread
From: Carsten Dominik @ 2008-06-12 10:54 UTC (permalink / raw)
To: Adam Spiers; +Cc: org-mode mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-12 10:54 ` Carsten Dominik
@ 2008-06-12 11:47 ` Adam Spiers
2008-06-13 8:18 ` Carsten Dominik
0 siblings, 1 reply; 13+ messages in thread
From: Adam Spiers @ 2008-06-12 11:47 UTC (permalink / raw)
To: org-mode mailing list
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-12 11:47 ` Adam Spiers
@ 2008-06-13 8:18 ` Carsten Dominik
2008-06-13 9:24 ` Adam Spiers
0 siblings, 1 reply; 13+ messages in thread
From: Carsten Dominik @ 2008-06-13 8:18 UTC (permalink / raw)
To: Adam Spiers; +Cc: org-mode mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-13 8:18 ` Carsten Dominik
@ 2008-06-13 9:24 ` Adam Spiers
2008-06-13 9:55 ` Paul R
2008-06-13 10:28 ` Carsten Dominik
0 siblings, 2 replies; 13+ messages in thread
From: Adam Spiers @ 2008-06-13 9:24 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-13 9:24 ` Adam Spiers
@ 2008-06-13 9:55 ` Paul R
2008-06-13 12:01 ` Adam Spiers
2008-06-13 14:16 ` Adam Spiers
2008-06-13 10:28 ` Carsten Dominik
1 sibling, 2 replies; 13+ messages in thread
From: Paul R @ 2008-06-13 9:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-13 9:24 ` Adam Spiers
2008-06-13 9:55 ` Paul R
@ 2008-06-13 10:28 ` Carsten Dominik
2008-06-13 11:48 ` Adam Spiers
1 sibling, 1 reply; 13+ messages in thread
From: Carsten Dominik @ 2008-06-13 10:28 UTC (permalink / raw)
To: Adam Spiers; +Cc: org-mode mailing list
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-13 10:28 ` Carsten Dominik
@ 2008-06-13 11:48 ` Adam Spiers
0 siblings, 0 replies; 13+ messages in thread
From: Adam Spiers @ 2008-06-13 11:48 UTC (permalink / raw)
To: org-mode mailing list
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 ;-)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: iCal export of repeated tasks
2008-06-13 9:55 ` Paul R
@ 2008-06-13 12:01 ` Adam Spiers
2008-06-13 12:56 ` Paul R
2008-06-13 14:16 ` Adam Spiers
1 sibling, 1 reply; 13+ messages in thread
From: Adam Spiers @ 2008-06-13 12:01 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: iCal export of repeated tasks
2008-06-13 12:01 ` Adam Spiers
@ 2008-06-13 12:56 ` Paul R
0 siblings, 0 replies; 13+ messages in thread
From: Paul R @ 2008-06-13 12:56 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Re: iCal export of repeated tasks
2008-06-13 9:55 ` Paul R
2008-06-13 12:01 ` Adam Spiers
@ 2008-06-13 14:16 ` Adam Spiers
1 sibling, 0 replies; 13+ messages in thread
From: Adam Spiers @ 2008-06-13 14:16 UTC (permalink / raw)
To: org-mode mailing list
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 ...
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-06-13 14:16 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-10 10:17 iCal export of repeated tasks Adam Spiers
2008-06-12 6:02 ` Carsten Dominik
2008-06-12 10:05 ` Adam Spiers
2008-06-12 10:54 ` Carsten Dominik
2008-06-12 11:47 ` Adam Spiers
2008-06-13 8:18 ` Carsten Dominik
2008-06-13 9:24 ` Adam Spiers
2008-06-13 9:55 ` Paul R
2008-06-13 12:01 ` Adam Spiers
2008-06-13 12:56 ` Paul R
2008-06-13 14:16 ` Adam Spiers
2008-06-13 10:28 ` Carsten Dominik
2008-06-13 11:48 ` Adam Spiers
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).