Jack Kamm <[email protected]> writes: >>> 2) Building an Emacs-native iCalendar-to-Org *importer* >> >> That would be a big project. To make it right, maybe we even need to do >> it beyond iCalendar and build a more generate import framework that will >> work for other formats, not just iCalendar. >> >> Richard, in theory, we may utilize ox.el infrastructure for this. But >> that would require making iCalendar AST to be compatible with what ox.el >> expects. > > I'll note that we do have an iCal->Org converter in org-caldav, it's > mainly meant to be used for syncing with Caldav servers but can also be > used standalone (org-caldav-convert-ics-to-datetree). > > But that importer is rather complex, and also it abuses many private > functions in icalendar.el (which I might need to finally fix when Emacs > 31 drops). So, rewriting the iCal->Org importer upstream in Org does > seem appealing. > > Ideally, the importer could be a faithful inverse of ox-icalendar, > though a major complication is that Org entries and iCalendar VEVENTs > are not 1:1 in ox-icalendar (a single Org entry can be exported to many > VEVENTs, e.g. if it contains multiple active timestamps -- this causes > all sorts of headaches for org-caldav, which requires a 1:1 mapping for > bidirectional sync, but uses ox-icalendar for Org->iCal conversion).
There's also the importer in Gnus-icalendar. Ideally that importer should rewritten to be a shim layer on top of whatever would be the public importing API. The upside of that could be that extending it would allow more features such as sending invites or fixs bugs such as the importer being able to override narrowed parts of the target document.
