Re: Timestamps in properties not exported by icalendar exporter

[Nick Dokos <ndokos@gmail.com>]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> David Engster <deng@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