Re: Improving Emacs' iCalendar support

[Richard Lawrence <rwl@recursewithless.net>]

Hi Adam,

Adam Porter <adam@alphapapa.net> writes:

> I don't have much to add to what's been said, but my first thought is 
> that a robust iCal library would probably be most useful for importing 
> and exporting between the iCal format, obviously.  So I'd suggest that 
> its API should help with transforming iCal data into other formats, 
> probably by converting it into a simple Lisp data structure that other 
> libraries could work with.  And then, it should also provide a function 
> to transform that data structure back into an iCal file.
>
> Also, it would be good if it were designed to be extensible in case the 
> standards receive updates, or in case vendor-specific functionality is 
> needed by users.

Yep, that's exactly the plan! Thanks for confirming that this is a good
idea.

> So I'd suggest looking at the existing Emacs/Org applications that use 
> iCal, and designing your API so that such applications would find it 
> easy to use (not that it should directly imitate what already exists, 
> unless such APIs are already ideal).

Yes, I was hoping especially to hear from Org/Gnus/diary developers if
they have any thoughts about what would make such a library easy (or
-ier) for them to use. Perhaps I should ask on their respective
lists...does Gnus have a separate mailing list? I will also grep through
the code to see if anything else in Emacs is using the icalendar--*
internal functions.

> Finally, I'd suggest that you consider using structs as the primary 
> internal data structure, because they provide setter and accessor 
> functions, which are helpful to developers (e.g. they help catch some 
> mistakes at compilation time).  If you do, I've found it helpful to 
> define an "etc" slot in various structs to which an alist or plist can 
> be attached, which provides the ability for the structs to carry 
> additional data that wasn't foreseen during its design.

Thanks, that's useful advice. I've been toying with the idea of using
EIEIO classes to represent at least the "component"-level data
structures (events, to-dos, journals, timezones, whole calendars), which
if I understand correctly use structs under the hood. But I don't really
have any experience with EIEIO and I'm not sure if the added complexity
of the object system will buy much over using plain structs. Do you have
any thoughts about this?

Best,
Richard