Carsten Dominik ([EMAIL PROTECTED]) wrote: > On Apr 29, 2008, at 4:12 PM, Adam Spiers wrote: > >Carsten Dominik ([EMAIL PROTECTED]) wrote: > >>On 7Nov2007, at 9:56 PM, Adam Spiers wrote: > >>>I use org-export-icalendar-combine-agenda-files to export my > >>>appointments to an .ics file which I point korganizer at. > >>> > >>>I noticed ages ago that if I have an appointment with a comma in, > >>>e.g.: > >>> > >>>** <2007-12-07 Fri 20:00> foo, bar > >>> > >>>korganizer always shows it as "bar" rather than "foo, bar". But I > >>>never got round to investigating whether it was a bug with the > >>>export or korganizer or something else ... until now :-) I just took a > >>>quick look at the iCalendar spec, which is RFC2445, and discovered that > >>>the SUMMARY field is defined as follows > >>> > >>> summary = "SUMMARY" summparam ":" text CRLF > >>> > >>> -- from http://tools.ietf.org/html/rfc2445#section-4.8.1.12 > >>> > >>>And the definition of 'text' in this context explicitly states that > >>>several characters, including commas, need to be escaped with a > >>>backslash: > >>> > >>> http://tools.ietf.org/html/rfc2445#section-4.3.11 > >>> > >>>Sure enough, when I edited the .ics file and manually escaped the > >>>comma, korganizer displayed the summary correctly. > >> > >>fixed, thanks > >> > >>- Carsten > > > >This appears to have regressed in some recent version ... > > Yes, seems there was still a bug. Fixed now.
Works great, thanks! > >Also, it would be great if a UID field could be generated for each > >event, perhaps by checksumming the contents of the event in some way. > >The RFC says: > > > > Conformance: The property MUST be specified in the "VEVENT", > > "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. > > > > -- http://tools.ietf.org/html/rfc2445#section-4.8.4.7 > > > >The checksum would ensure that the UID field only changes when the > >event details check, which would be a first step towards helping > >synchronisation systems. I'm vaguely suspicious that the lack of UIDs > >currently confuses Google Calendar too. > > A UID may be good. However I think changing the UID when changing the > entry would be bad, because this would exactly *disable* synchronization. > To synchronize, you must know which entries to compare, and this is only > possible with a persistent UID. Doh - you are right of course. > I guess we could create one, but this UID would then have to be stored > in the entry, as a property. Exporting to ical again must then re-use the > old uid each time. > > My org-id.el in the contrib directory allows already to create unique > identifiers, and it would be easy enough to include the domain to make > them truely unique, wordwide. > > However, right now I am hesitating to force a property drawer onto > every entry that ever is exported to iCalendar. But as an option, this might > > really be good and eventually allow true synchronization. I understand your hesitation - as an option that sounds perfect. I forgot to mention before that gcaldaemon http://gcaldaemon.sourceforge.net/ which is a very nice piece of software indeed, requires the UID field. If you provided that, then gcaldaemon would give us the solution to at least unidirectional synchronisation with Google Calendar. I have experimented with simply scp'ing the generated .ics file to a private location on my webserver and pointing Google Calendar at that private URL, but there is no way to force Google Calendar to reload the data after subsequent scp invocations. > P.S. Adam, I emailed you twice privately in the last few weeks, but > did not get any reply. Hrm :-/ I have issues with private mail currently due to receiving between 5,000 and 10,000 spam a day (not to mention being busy and still having yet to perfect GTD ;-). However I just replied to a couple of recent ones - were they the ones you were referring to? _______________________________________________ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode