Re: [O] Recurring events with exceptions

[Skip Collins]

> (and (your-sexp-here) (not (except-dates-here)))

Pardon a slightly off-topic rant. I have yet to find calendar software
(org included) that handles repeating appointments with the kind of
flexibility that would make them really useful. First, typical
real-world repeating appointments do not follow a rigid pattern such
as "visit the gym every monday from 7pm to 9pm." I know that I will
not be following that pattern 50 years from now. But the default
repeat pattern in most software does not include an end date.
Infinitely repeating appointments are just stupid. Second, the whole
concept of an exception to a repeating appointment is broken. It
presumes that the pattern is the norm and the exception is, well,
exceptional. None of my weekly meetings actually meets every week in a
given year. The code above illustrates the problem. What if I just
want to move one instance by a half-hour? The difference between
deleting an instance and changing or adding an instance is hard to
capture when basing everything off of a rigid pattern.

In my opinion, a better framework for dealing with repeating
appointments would be to view them as a list of individual instances
that can be managed as a collection. When creating a repeating
appointment, the user should be able to generate a list that follows
some pattern (e.g. every monday at 7pm), with a mandatory end date.
The user should also be able to easily add or subtract arbitrary
instances to or from the list. Actions can be performed on all
instances in a collection or on individual instances. The collection
of instances could be defined by a shared UID or tag. But each
instance should be flexible enough to have its own title, date, time,
duration, invitee list, location, etc. It should also be possible to
separate (or copy) individual instances from the repeat collection.
Using arbitrarily complex sexp functions to achieve reasonably
flexible repeating appointments seems like overkill when a properly
structured and managed list can accomplish the desired effect.

Of course the devil is in the implementation details.