org-caldav feedback

org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 624 bytes --]

Hi,
we just tried org-caldav and it seems to work very nice.
We use Sogo http://www.sogo.nu/ and hence David might like to ad Sogo on
the list of possible caldav servers.
We will test further and report problems and success ;)
Thumbs up. For me org-caldav is a new success story of org-mode, please try
to get it into the org-mode standard package :)
Any plans to sync tasks too?

Greetings

Torsten

CC. Since Sogo does not allow a print view. Does someone know how to create
a printable weekly calendar which contains org-agenda entries?
I barley remember there was a possibility to create a PDF but can't find it
anymore

[-- Attachment #2: Type: text/html, Size: 831 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> we just tried org-caldav and it seems to work very nice.
> We use Sogo http://www.sogo.nu/ and hence David might like to ad Sogo on the
> list of possible caldav servers.

Thanks, that's good news. I'm actually pretty surprised that it works
right out of the box.

>  Any plans to sync tasks too?

Could you elaborate? What exactly to you mean by 'task'? Everything with
an active timestamp should get synced.

-David

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

Hi David,

hehehe well we just started testing it a bit. Don't frighten there are
problems... ;)
So far, we could see appointments in the SOGo calendar which magically
appeared after calling sync.

Just to get started with problems:

I noticed that there seems to be a problem with syncing events back to org.
E.g., if I move a entry from within org-caldav, after sync I get a message
about sync caldav->org, they still appear at the same position in the
org-mode fie but the entry has no date at all. The old entry can be found
in org-caldav-backup.org

Furthermore, I notice, that entries have a 1 hour shift (an appointment at
9:00 in org appears as 10:00 in SOGo). I set already the timezone but the
problem remain. Since 1 hour is exactly the time difference between UTC and
the local timezone (Europe/Berlin), as well as summer/winter time settings,
I would assume the problem is related to this. I know that this kind of
stuff can be a mess.

I would like to say that I really love the debug and sync messages. For
those kind of procedures, I always frighten that something goes wrong
unnoticed and I was really happy to see a the user readable status messages.

I also noticed the files org-caldav-2094e16.el and org-caldav-backup.org.
However, they are stored in my .emacs.d folder. Would it make sens to have
an option to save them relatively to the org-file? E.g. relative to the
path set in org-caldav-files? That would help to keep infos together and
might be even a security concern (e.g., you might forget to move or delete
backup infos in .emacs.d)!?

Thanks, that's good news. I'm actually pretty surprised that it works
> right out of the box.
>
> >  Any plans to sync tasks too?
>

SOGo calendars allow to set events and tasks (not sure whether tasks are
part of the caldav specs). From what I can say they differ only in the fact
that a task has a certain deadline and can be marked done. Thus, this would
be equivalent to a TODO DEADLINE entry in org-mode

Thanks again for this great work and please tell us how to help you to get
SOGo 100% compatible, we would like to help as much as we can.

Greetings

Torsten

[-- Attachment #2: Type: text/html, Size: 2738 bytes --]

Re: org-caldav feedback

[Eric S Fraga]

Torsten Wagner <torsten.wagner@gmail.com> writes:
> Thumbs up. For me org-caldav is a new success story of org-mode, 
> please try to get it into the org-mode standard package :) 

+1

It would be great to see org-caldav added to contrib/ at the very 
least (avoiding having to track two different git 
repositories...).
 
> Any plans to sync tasks too? 

This could be useful but would require that the org side match 
VTODO objects closely?  Org is very flexible in the way it defines 
and handles todo elements, allowing a user to completely change 
how these entries are defined and handled.  More importantly, 
within a given org file, you can have different todo types 
(sequences of states).
 
> CC. Since Sogo does not allow a print view. Does someone know 
> how to create a printable weekly calendar which contains 
> org-agenda entries?  I barley remember there was a possibility 
> to create a PDF but can't find it anymore 
 
Maybe have a look at

,----[ C-h f org-agenda-write RET ] | org-agenda-write is an 
interactive compiled Lisp function in | `org-agenda.el'.  |  | 
(org-agenda-write FILE &optional OPEN NOSETTINGS AGENDA-BUFNAME) | 
| Write the current buffer (an agenda view) as a file.  | 
Depending on the extension of the file name, plain text (.txt), | 
HTML (.html or .htm) or Postscript (.ps) is produced.  | If the 
extension is .ics, run icalendar export over all files used | to 
construct the agenda and limit the export to entries listed in the 
| agenda now.  | With prefix argument OPEN, open the new file 
immediately.  | If NOSETTINGS is given, do not scope the settings 
of | `org-agenda-exporter-settings' into the export 
commands.  This is used when | the settings have already been 
scoped and we do not wish to overrule other, | higher priority 
settings.  | If AGENDA-BUFFER-NAME, use this as the buffer name 
for the agenda to write.  |  | [back] `----  HTH,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87

Re: org-caldav feedback

[Christian Egli]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> CC. Since Sogo does not allow a print view. Does someone know how to
> create a printable weekly calendar which contains org-agenda entries?
> I barley remember there was a possibility to create a PDF but can't
> find it anymore 

There are the cal-tex-* functions which produce tex from diary files.
See the info entry on Writing Calendar Files. Also there is a Makefile
which uses the cal-tex-* functions to generate hipster style printouts
in contrib/scripts/org2hpda. This might serve as an inspiration.

Thanks
Christian
-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

Hey David,
could you please help me and steer me in the right direction to find the
cuprit which makes the caldav calendar lagging an hour compared to the
timestamps in org-mode.
I use Linux, not sure that might be releated or not.

Thanks

Torsten


On 17 January 2013 20:05, David Engster <deng@randomsample.de> wrote:

> Torsten Wagner writes:
> > we just tried org-caldav and it seems to work very nice.
> > We use Sogo http://www.sogo.nu/ and hence David might like to ad Sogo
> on the
> > list of possible caldav servers.
>
> Thanks, that's good news. I'm actually pretty surprised that it works
> right out of the box.
>
> >  Any plans to sync tasks too?
>
> Could you elaborate? What exactly to you mean by 'task'? Everything with
> an active timestamp should get synced.
>
> -David
>

[-- Attachment #2: Type: text/html, Size: 1355 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> Hey David,
> could you please help me and steer me in the right direction to find the cuprit
> which makes the caldav calendar lagging an hour compared to the timestamps in
> org-mode.

It's difficult. I will need to add some (optional) excessive debugging
output for seeing what's happening. Or maybe you could provide an
account on some server running SUGo so that I can debug this myself.

I guess the easy way out would be to add a variable which allows
shifting the time by X hours before sending it to the server. But I'd
rather avoid that kludge.

-David

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> I also noticed the files org-caldav-2094e16.el and org-caldav-backup.org.
> However, they are stored in my .emacs.d folder. Would it make sens to have an
> option to save them relatively to the org-file? E.g. relative to the path set
> in org-caldav-files? That would help to keep infos together and might be even a
> security concern (e.g., you might forget to move or delete backup infos in
> .emacs.d)!?

Just adapt the variables org-caldav-backup-file and org-caldav-save-directory. 

> SOGo calendars allow to set events and tasks (not sure whether tasks are part
> of the caldav specs). From what I can say they differ only in the fact that a
> task has a certain deadline and can be marked done. Thus, this would
> be equivalent to a TODO DEADLINE entry in org-mode

I'm not very familiar with the VTODO stuff. It doesn't make much of a
difference as far as CalDAV is concerned, but the import/export will
surely be tricky. For now, I'll concentrate on making the existing
features more stable.

-David

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

Hi David,

the variable would be a treatment like a pain-killer ;)
I frighten that the real reason (e.g. summer/winter time) might disappear
and then suddenly the time would be wrong again.
You might can try

   http://sogo-demo.inverse.ca/SOGo/dav/sogo1/Calendar/personal/

which is the demo account of the Sogo.
For sure, I am more then willing to help with debugging. Just let me know
where to look.

If you can't use the demo account let me know and I will check if you can
get access to our Sogo installation.


Thanks

Totti

On 21 January 2013 20:25, David Engster <deng@randomsample.de> wrote:

> Torsten Wagner writes:
> > Hey David,
> > could you please help me and steer me in the right direction to find the
> cuprit
> > which makes the caldav calendar lagging an hour compared to the
> timestamps in
> > org-mode.
>
> It's difficult. I will need to add some (optional) excessive debugging
> output for seeing what's happening. Or maybe you could provide an
> account on some server running SUGo so that I can debug this myself.
>
> I guess the easy way out would be to add a variable which allows
> shifting the time by X hours before sending it to the server. But I'd
> rather avoid that kludge.
>
> -David
>

[-- Attachment #2: Type: text/html, Size: 1893 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> You might can try
>
>    http://sogo-demo.inverse.ca/SOGo/dav/sogo1/Calendar/personal/
>
> which is the demo account of the Sogo. 

Thanks. That'll work.

After a bit of fiddling it seems that SOGo really really wants a
timezone definition. I have no idea how those can be generated
on-the-fly. I have a hunch you have to hard-code them.

Anyway, you can put the definition you need into
org-caldav-calendar-preamble. But first you need the correct one.

For getting it, just create an event in your calendar. Then run
org-caldav-sync and it should be put into your org-caldav-inbox. Then,
evaluate

(pop-to-buffer (org-caldav-get-event "ID"))

where you have replaced "ID" with the ID of the event. You should see a
buffer with the iCalendar entry in it. Then copy&paste everything from
BEGIN:VCALENDAR to END:VTIMEZONE into org-caldav-calendar-preamble. For
example, for Europe/Berlin it now seems to work with

(setq org-caldav-calendar-preamble
  "BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 2.0.3a//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
")

If it works for you with such a timezone definition, it'd be interesting
to know if SOGo needs all of that or if you could drop most of this
stuff.

-David

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

Hi David,

great thanks a lot this solved the time shift problem.
I did not had time to play with the different parameters. For now I simply
added all of them.
I guess it has to do either with the timezone or with the daylight settings.
Maybe you want to add this to a "How-to install for SOGo" as a workaround.

One problem remain. If I change something in the caldav calendar, the time
information in org get lost completely.
E.g.
* Meeting <2013-01-16 Wed 14:00>
becomes
* Meeting
It subsitutes the right entry and hence I believe it gets the ID stuff
right. However, it seems to have trouble to interpret the time information
right (and ignore them?).
If there is a way to help you debugging this please let me know.

Thanks again a lot


Torsten


(setq org-caldav-calendar-preamble
>   "BEGIN:VCALENDAR
> PRODID:-//Inverse inc./SOGo 2.0.3a//EN
> VERSION:2.0
> BEGIN:VTIMEZONE
> TZID:Europe/Berlin
> X-LIC-LOCATION:Europe/Berlin
> BEGIN:DAYLIGHT
> TZOFFSETFROM:+0100
> TZOFFSETTO:+0200
> TZNAME:CEST
> DTSTART:19700329T020000
> RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
> END:DAYLIGHT
> BEGIN:STANDARD
> TZOFFSETFROM:+0200
> TZOFFSETTO:+0100
> TZNAME:CET
> DTSTART:19701025T030000
> RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
> END:STANDARD
> END:VTIMEZONE
> ")
>
> If it works for you with such a timezone definition, it'd be interesting
> to know if SOGo needs all of that or if you could drop most of this
> stuff.
>
> -David
>

[-- Attachment #2: Type: text/html, Size: 2007 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> I did not had time to play with the different parameters. For now I simply
> added all of them.
> I guess it has to do either with the timezone or with the daylight settings.
> Maybe you want to add this to a "How-to install for SOGo" as a workaround.

I think I found a better solution. I pushed a change to org-caldav which
allows to set org-icalendar-timezone to the string "UTC", which will put
events using universal time. The server should then transpose it to the
timezone you have set in your SOGo preferences. It works for me (for
SOGo, mind you; other calendar servers don't work well with that).

> One problem remain. If I change something in the caldav calendar, the time
> information in org get lost completely.
> E.g.
> * Meeting <2013-01-16 Wed 14:00>
> becomes
> * Meeting
> It subsitutes the right entry and hence I believe it gets the ID stuff right.
> However, it seems to have trouble to interpret the time information right (and
> ignore them?).
> If there is a way to help you debugging this please let me know.

My test suite runs fine with the SOGo server, so I'm guessing it has to
do with how you format your entries. Does this also happen when you put
the timestamp underneath the heading?

On a general note, I find manipulating Org entries rather delicate and
wonder why there are no helper functions to change things like headings,
timestamps, etc., which take care of the multitude of possibilities how
entries can be formatted. My guess is that org-elements might be the
solution for this, but I haven't looked at it yet...

-David

Re: org-caldav feedback

[Eric S Fraga]

David Engster <deng@randomsample.de> writes:

[...]

> I think I found a better solution. I pushed a change to org-caldav which
> allows to set org-icalendar-timezone to the string "UTC", which will put
> events using universal time. The server should then transpose it to the
> timezone you have set in your SOGo preferences. It works for me (for
> SOGo, mind you; other calendar servers don't work well with that).

David,

for those of us not using SOGo (I use Google), what should we do?  I've
not updated the version of org-caldav I'm using yet.

By the way, I will take this opportunity to say that org-caldav is
working like a charm for me.  Although I haven't really pushed it to the
limits, for day to day stuff it's working very well.  I've had to clear
out the org-caldav-xxx.el file in .emacs.d a couple of times but that's
typically due to my doing things on the same entry in both calendar
systems (org and Google).  However, clearing out the file and having
org-caldav re-sync everything from scratch is a simple and good enough
solution for when problems arise.

Thanks again,
eric

-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 1678 bytes --]

Hi Eric,

If I understood David right, the "UTC" option is just an addition to the
already present options.
Thus, if you used e.g. "Europe/Berlin" before, you do not need to change
anything and in fact, you shouldn't see a difference.
However, if you face time shifts between org and the caldav calendar you
might try "UTC".

Hope that helps

Torsten

On 23 January 2013 07:00, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:

> David Engster <deng@randomsample.de> writes:
>
> [...]
>
> > I think I found a better solution. I pushed a change to org-caldav which
> > allows to set org-icalendar-timezone to the string "UTC", which will put
> > events using universal time. The server should then transpose it to the
> > timezone you have set in your SOGo preferences. It works for me (for
> > SOGo, mind you; other calendar servers don't work well with that).
>
> David,
>
> for those of us not using SOGo (I use Google), what should we do?  I've
> not updated the version of org-caldav I'm using yet.
>
> By the way, I will take this opportunity to say that org-caldav is
> working like a charm for me.  Although I haven't really pushed it to the
> limits, for day to day stuff it's working very well.  I've had to clear
> out the org-caldav-xxx.el file in .emacs.d a couple of times but that's
> typically due to my doing things on the same entry in both calendar
> systems (org and Google).  However, clearing out the file and having
> org-caldav re-sync everything from scratch is a simple and good enough
> solution for when problems arise.
>
> Thanks again,
> eric
>
> --
> : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
> : in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613
>
>
>

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

Hi David,

time is correct now using "UTC" thanks a lot.


My test suite runs fine with the SOGo server, so I'm guessing it has to
> do with how you format your entries. Does this also happen when you put
> the timestamp underneath the heading?
>
> Tested and you are right. Adding a timestamp in the body doesn't get lost
during sync.
Actually, I guess the problem is a combination of export and import to
org-mode.
During the export, the timestamp gets read in correctly, however, it get
stripped from the Summary line (which is good).
During the import, org-caldav does not find a timestamp in the body to
update and does nothing (wild speculation).

A possible solution would be to teach org-caldav to update the timestamp
within the node header if available.
I see the problem that you might changed the text in the summary field in
the caldav calendar, which potentially mess up the header (where to place
the old  timestamp within the context of the new text?!) but for now, I
would suggest to simply search for a timestamp within the node-header and
update it by adding a new timestamp at the very end (but before tags ;) ).
In addition a new variable

org-caldav-timestamp-pos which can be either "header" or "body"

could indicate where to place the timestamp for a new entry coming from
caldav.

Thanks again for this great work and I really appreciate your help and
effort

Torsten






On a general note, I find manipulating Org entries rather delicate and
> wonder why there are no helper functions to change things like headings,
> timestamps, etc., which take care of the multitude of possibilities how
> entries can be formatted. My guess is that org-elements might be the
> solution for this, but I haven't looked at it yet...
>
> -David
>

[-- Attachment #2: Type: text/html, Size: 2475 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> If I understood David right, the "UTC" option is just an addition to the
> already present options.
> Thus, if you used e.g. "Europe/Berlin" before, you do not need to change
> anything and in fact, you shouldn't see a difference.

Yes, exactly.

-David

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> I see the problem that you might changed the text in the summary field in the
> caldav calendar, which potentially mess up the header (where to place the old
>  timestamp within the context of the new text?!) but for now, I would suggest
> to simply search for a timestamp within the node-header and update it by adding
> a new timestamp at the very end (but before tags ;) ).

Yes, something like this needs to be done. As I've written in my last
mail, I'm hoping for a more general solution. I'm guessing that
org-elements can help me with this, but I haven't yet looked at it in
detail.

> In addition a new variable
>
> org-caldav-timestamp-pos which can be either "header" or "body"
>
> could indicate where to place the timestamp for a new entry coming from caldav.

Hmm. What are the advantages of putting it in the header?

-David

Re: org-caldav feedback

[David Engster]

Eric S. Fraga writes:
> I've had to clear out the org-caldav-xxx.el file in .emacs.d a couple
> of times but that's typically due to my doing things on the same entry
> in both calendar systems (org and Google).

If you change an item in Org as well as in the Calendar, the calendar
entry should simply get overwritten with the change you did in Org. So
while this "Org always wins" strategy doesn't qualify as proper conflict
handling, I still wonder why you had to restart from scratch?

Anyway, this is a temporary issue; I will add proper conflict handling
in the coming weeks.

-David

Re: org-caldav feedback

[Eric S Fraga]

Torsten Wagner <torsten.wagner@gmail.com> writes:

> Hi Eric,
>
> If I understood David right, the "UTC" option is just an addition to the
> already present options.
> Thus, if you used e.g. "Europe/Berlin" before, you do not need to change
> anything and in fact, you shouldn't see a difference.
> However, if you face time shifts between org and the caldav calendar you
> might try "UTC".
>
> Hope that helps

It does.  Thanks!
I don't actually specify anything and everything seems to be fine re:
time zones.  I will upgrade my copy of org-caldav.
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613

Re: org-caldav feedback

[Eric S Fraga]

David Engster <deng@randomsample.de> writes:

> Eric S. Fraga writes:
>> I've had to clear out the org-caldav-xxx.el file in .emacs.d a couple
>> of times but that's typically due to my doing things on the same entry
>> in both calendar systems (org and Google).
>
> If you change an item in Org as well as in the Calendar, the calendar
> entry should simply get overwritten with the change you did in Org. So
> while this "Org always wins" strategy doesn't qualify as proper conflict
> handling, I still wonder why you had to restart from scratch?

Who knows?  I was mucking about quite a bit and I obviously confused the
system!  As I said, no worries as the fix was straightforward.

> Anyway, this is a temporary issue; I will add proper conflict handling
> in the coming weeks.

I look forward to it!

Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-837-ge37613

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> Tested and you are right. Adding a timestamp in the body doesn't get
> lost during sync.  Actually, I guess the problem is a combination of
> export and import to org-mode.  During the export, the timestamp gets
> read in correctly, however, it get stripped from the Summary line
> (which is good).  During the import, org-caldav does not find a
> timestamp in the body to update and does nothing (wild speculation).
>
> A possible solution would be to teach org-caldav to update the timestamp within
> the node header if available.

I pushed a change which should correctly deal with timestamps inside the
header line. Please let me know if this works for you.

-David

Re: org-caldav feedback

[Torsten Wagner]

[-- Attachment #1: Type: text/plain, Size: 1302 bytes --]

Hi David,


On 2 February 2013 17:00, David Engster <deng@randomsample.de> wrote:

> I pushed a change which should correctly deal with timestamps inside the
> header line. Please let me know if this works for you.
>

Sorry for the long delay to your patch.
First I thought its working perfect.
However, I noticed the following small glitch. I think its a minor problem.
Syncing back from caldav to org creates the following.

Original in org-mode

TODO Neuer Termin mit Foo und Bar <2013-03-06 Wed 10:00-10:00>
    :PROPERTIES:
    :ID:       8a9651c0-faee-4416-afa6-979e328a3d15
    :END:

Synching to caldav work flawless
In SOGo I can find

TODO Neuer Termin mit Foo und Bar
*Please note there is a space at the end of the line. Not sure if this
might trouble*

Now I make a tiny change e.g. change the length of the appointment from
within SOGo and sync back I get

TODO TODO Neuer Termin mit Foo und Bar r<2013-03-06 Wed 10:00-11:00>
    :PROPERTIES:
    :ID:       8a9651c0-faee-4416-afa6-979e328a3d15
    :END:

As you can see the TODO doubled and the last character of the title is
repeated.

I guess its simply some regexp, which needs some finetuning.

All the best and thanks a lot

Torsten

CC. Did you had a chance to look into calfw and think about how to make use
of it for org-caldav?

[-- Attachment #2: Type: text/html, Size: 3078 bytes --]

Re: org-caldav feedback

[David Engster]

Torsten Wagner writes:
> Now I make a tiny change e.g. change the length of the appointment from within
> SOGo and sync back I get
>
> TODO TODO Neuer Termin mit Foo und Bar r<2013-03-06 Wed 10:00-11:00>
>     :PROPERTIES:
>     :ID:       8a9651c0-faee-4416-afa6-979e328a3d15
>     :END:
>
> As you can see the TODO doubled and the last character of the title is
> repeated.
>
> I guess its simply some regexp, which needs some finetuning.

Thank you for this bug report. I'll look into it.

> CC. Did you had a chance to look into calfw and think about how to make use of
> it for org-caldav?

Not sure what you have in mind here.

-David