Re: Improving Emacs' iCalendar support

[Richard Lawrence <rwl@recursewithless.net>]

Hi Ferdinand,

Ferdinand Pieper <ferdi@nand.xyz> writes:

> Emacs is really lacking a central parser for iCalendar and a common
> internal representation of iCalendar items. I have ran over this
> several times, but was always very quick to shy away from working on a
> central overhaul of icalendar.el. I resorted to small extensions of
> gnus-icalendar.el to bring event (request) creation to gnus, which
> still is very much in a prototype state [1].
>
> While I started extending the gnus-icalendar-event EIEIO class to
> support property parameters, it ended up being very cumbersome to
> create new event objects with all parameters correctly set.

This is good feedback, thank you. Can you say more about what exactly
was cumbersome about it? (Was it the need to call various constructors,
instead of just consing up lists? or the need to interact with objects
via setters/getters? or lack of validation of parameter lists? or...?)

> I think structs could be a good fit for the internal representation.
> Creating these from scratch should still be kept fairly
> straightforward for ease of use. There could also be a translation
> function that creates the appropriate struct from a very basic list
> representation like this:
>
> --8<---------------cut here---------------start------------->8---
> (VCALENDAR
>  ((PRODID nil "-//...")
>   (VERSION nil "2.0"))
>  (VEVENT
>   (;; ...
>    (DTSTART ((VALUE "DATE")) "20241201")
>    (DTEND ((VALUE "DATE")) "20241231"))))
> --8<---------------cut here---------------end--------------->8---

Yes, as I'm sure you're aware, icalendar.el creates a list
representation like this. I've been thinking we might need such a
function anyway for the sake of backward compatibility. And the more I
think about it, the more I realize that a list representation with a few
accessors should be just fine for the "container" types (components,
properties, attribute lists).

The disadvantage of a representation like the one above is there is no
structure yet in the *value* types: e.g. "20241201" is just a string,
not a date. This is fine for export (assuming you've already validated
the data...) but when reading the data, one needs to parse these values
too, and this is what I've been using structs for so far.

So do you think it would still be too cumbersome to have a
representation like

> ... (DTSTART ((VALUE "DATE")) (icalendar-read-date "20241201"))

or even just

> ... (DTSTART ((VALUE "DATE")) ('icalendar-date . "20241201"))

where in the latter, 'icalendar-date is a cl type symbol and some magic
type dispatch will call the associated read function on the string at
an appropriate time?

Best,
Richard