Jack Kamm <[email protected]> writes: > Thanks Richard, this looks like very exciting work. I should have some > time in mid-March to look into this.
Thanks! It was a lot of work and I'm glad people are starting to see its utility. I'm looking forward to your feedback when you have time. > At a glance, two things jump out at me: > > First, the diary-rrule sexp. This could greatly expand the power of > repeaters in Org-mode through the use of diary-timestamps. Also, in > org-caldav (which I am currently the de-facto maintainer of), I had > previously wished for this [1] as it would allow us to have proper > bidirectional sync for complex repeating events, so I am very excited > to see you've done this. A brief word of caution about this: the diary-rrule sexp is at the moment a bit of a kludge and only supports date-level recurrences (see the comments in the source code), mainly because the diary has no syntax for time zones. AFAIK this is still true for Org as well. Full time zone support should be in place before we attempt "proper" bidirectional sync; otherwise there will be information loss. As I said in another message, I think just directly displaying iCalendar data in the agenda is often a better approach than attempting bidirectional sync, for reasons like this. > Second, icalendar-mode.el and syntax highlighting. We've previously > discussed wanting to support icalendar export snippets [2], but among > other challenges, a major weakness was the lack of syntax highlighting > which would make it difficult to write such blocks -- but now I am happy > to learn icalendar-mode.el has removed that obstacle. Great! (The syntax highlighting is functional but can definitely be improved. If anyone here has more experience with font lock and wants to take a look at the code in icalendar-mode.el, patches are welcome...) > Looking beyond ox-icalendar.el -- I think it would be really, really > nice if Org's basic syntax integrated better with iCalendar, analogous > to Org's support of LaTeX fragments. It would make Org a lot more > powerful -- there are some things (especially around recurrences) that > are easy in iCalendar but difficult or impossible in Org (e.g. repeating > multiday events). Indeed. The same word of caution applies here too, though. It *looks* simple to represent an iCalendar event on its own in a source block, but in reality representing dates and times in iCalendar syntax also requires referring to one or more time zone definitions, which are often much longer than the event data itself. (These could be in another source block, of course, as long as the cross-references work.) >>> 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. (Yes, I was once an org-caldav user myself, and these are some of the frustrations that eventually drove me to replace icalendar.el...) > 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). Do you know what the reason for this is? Why not use one VEVENT with multiple RDATEs? Could this aspect of ox-icalendar change? -- Best, Richard
