Nicolas Goaziou <n.goaz...@gmail.com> writes: > David Engster <d...@randomsample.de> writes: > >> Yes, I could do that for my specific setup. But it would be nice if this >> stuff could "just work", so that things like Outlook calendar invites >> can be directly exported to .ics. > > AFAIU, we're talking about a third-party package which implements its > own UI. We cannot support every UI in the wild. >
I was confused at first because David has (had?) his own gnus-icalendar package, but I believe he means the gnus-icalendar that is part of gnus. That's probably a bit more official than a third-party package in the wild, but I appreciate Nicolas's desire to control the chaos. It might make more sense to advertise an API/convention/whatever that such packages can use and provide a patch to modify gnus-icalendar accordingly. After all, I presume gnus-icalendar can only be used with gnus, so other mailers will have to have their own icalendar->org. If each picks its own convention, chaos reigns. We just need to come up with the "standard" and advertise it appropriately. Maybe something like this: "provide the starting time/duration information as a scheduled timestamp, and optionally provide everything in properties. The names of the properties should be the names that gnus-icalendar currently uses (explicitly listed out, of course)." >> I mean, those entries show up in the agenda, so I found it rather >> surprising that they are completely ignored by the exporter. > > This is an agenda bug, which probably use a regexp to find timestamps. > But timestamps in properties are not valid Org timestamps, per Org > syntax. > If gnus-icalendar is modified as above, then when the agenda is rewritten using org-element, things are not going to break. >> I think it would make sense if the exporter also looked for >> time-stamps in the properties. > > There are already plenty of locations to use timestamps. We have > scheduled, deadline, plain timestamps... I don't think we need more of > them. > > Also, a hook is easy enough to implement in this situation. > -- Nick