[-- 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 --]
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 #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 --]
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
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
[-- 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 --]
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
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
[-- 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 --]
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
[-- 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 --]
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
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 #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 --]
[-- 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 --]
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
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
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
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
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
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
[-- 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 --]
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