Re: org-caldav can't find org-prepare-agenda-buffers

[Vincent Beffara <vbeffara@ens-lyon.fr>]

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

Hi,

Agreed ... I believe the only problem will occur when one of a multiply occurring event is edited / deleted on the cal side. I have nothing more constructive to propose than just "don't do that" ... My use-case is just as a way to push org changes to cal and nothing more, and for bidirectional people who would create events on cal and sync, not much bad would happen I believe. But you're right, conflict resolution (which is what that would be) will be a problem. Would have to manage reference counts etc, for little benefit. Who is using multiply occurring events anyway?

Attached is what I am proposing: absent multiply occurring events, the org and cal IDs are the same (which is as it was except for the missing 1 in a regexp). For the second occurrence, the TS2- prefix is conserved, and so on - but it is trimmed when fed to org-id etc. As you say, it is not correct and will lead to problems down the road, but I really wanted all occurrences to appear in iCal ;-)

Cheers,

/v 
> I appreciate your work, of course, but let me add a word of warning. I
> think if you give up the one-to-one correspondence that one Org event
> has exactly *one* event in the remote calendar, you are entering a world
> of pain.
> 
> Remember that there are three things: new items, changed items and
> deleted items. Since these can happen on both sides, you have to figure
> out six different cases which must be handled properly. As you've
> already experienced, the changes on the calendar side are more
> difficult. What happens if you delete one of the events that stems from
> one Org entry? You would first have to figure out which timestamp
> created it, but how? Timestamps don't have UIDs, only the full entry has
> one. So you would have to somehow add this information to the event
> database which gets stored to disk. You might get this to work, but I
> have a gut feeling that you'll loose robustness. For example, the Google
> calendar CalDAV interface is pretty slow and not very reliable, so a
> robust resume functionality is essential.
> 
> Also, I deliberately shoved conflict handling at the side for the
> moment, but this is a feature which will have to be added one day, and
> will complicate things much more.
> 
> -David 


[-- Attachment #2: org-caldav-multi.patch --]
[-- Type: application/octet-stream, Size: 3409 bytes --]

commit 24b8a666f9d7b0b12a0d4cb5937d17952a644b0a
Author: Vincent Beffara <vbeffara@ens-lyon.fr>
Date:   Thu Mar 14 00:50:12 2013 +0100

    Allow multiply occurring events

diff --git a/org-caldav.el b/org-caldav.el
index 0383366..73445ee 100644
--- a/org-caldav.el
+++ b/org-caldav.el
@@ -413,7 +413,7 @@ Are you really sure? ")))
 
 (defun org-caldav-generate-md5-for-org-entry (uid)
   "Find Org entry with UID and calculate its MD5."
-  (let ((marker (org-id-find uid t)))
+  (let ((marker (org-id-find (org-caldav-trim-uid uid) t)))
     (when (null marker)
       (error "Could not find UID %s." uid))
     (with-current-buffer (marker-buffer marker)
@@ -606,7 +606,7 @@ which can only be synced to calendar. Ignoring." uid))
 	;; This is a changed event.
 	(org-caldav-debug-print
 	 1 (format "Event UID %s: Changed in Cal --> Org" uid))
-	(let ((marker (org-id-find (car cur) t)))
+	(let ((marker (org-id-find (org-caldav-trim-uid (car cur)) t)))
 	  (when (null marker)
 	    (error "Could not find UID %s." (car cur)))
 	  (with-current-buffer (marker-buffer marker)
@@ -648,7 +648,7 @@ which can only be synced to calendar. Ignoring." uid))
   ;; (Maybe) delete entries which were deleted in calendar.
   (unless (eq org-caldav-delete-org-entries 'never)
     (dolist (cur (org-caldav-filter-events 'deleted-in-cal))
-      (org-id-goto (car cur))
+      (org-id-goto (org-caldav-trim-uid (car cur)))
       (when (or (eq org-caldav-delete-org-entries 'always)
 		(and (eq org-caldav-delete-org-entries 'ask)
 		     (y-or-n-p "Delete this entry? ")))
@@ -775,9 +775,15 @@ Returns nil if there are no more events."
 		      (forward-line 1)
 		      (point))))
 
+(defun org-caldav-trim-uid (uid)
+  "Remove extra export prefixes from a UID.
+This is to take care of multiply occurring events, the UID kept
+by org-caldav contains TS2- and so on but the org ID doesn't."
+  (replace-regexp-in-string "^[A-Z][A-Z][0-9]?-" "" uid))
+
 (defun org-caldav-rewrite-uid-in-event ()
   "Rewrite UID in current buffer.
-This will strip prefixes like 'DL' or 'TS' the Org exporter puts
+This will strip prefixes like 'DL1' or 'TS1' the Org exporter puts
 in the UID and also remove whitespaces. Throws an error if there
 is no UID to rewrite. Returns the UID."
   (save-excursion
@@ -786,7 +792,7 @@ is no UID to rewrite. Returns the UID."
      ((re-search-forward "^UID:\\(orgsexp-[0-9]+\\)" nil t)
       ;; This is a sexp entry, so do nothing.
       (match-string 1))
-     ((re-search-forward "^UID:\\(\\s-*\\)\\([A-Z][A-Z]-\\)?\\(.+\\)\\s-*$"
+     ((re-search-forward "^UID:\\(\\s-*\\)\\([A-Z][A-Z]1?-\\)?\\(.+\\)\\s-*$"
 			 nil t)
       (when (match-string 1)
 	(replace-match "" nil nil nil 1))
@@ -962,7 +968,7 @@ If COMPLEMENT is non-nil, return all item without errors."
 
 (defun org-caldav-get-heading-from-uid (uid)
   "Get org heading from entry with UID."
-  (let ((marker (org-id-find uid t)))
+  (let ((marker (org-id-find (org-caldav-trim-uid uid) t)))
     (if (null marker)
 	"(Could not find UID)"
       (with-current-buffer (marker-buffer marker)
@@ -983,7 +989,7 @@ If COMPLEMENT is non-nil, return all item without errors."
 	       '(face link))
     (beginning-of-line)
     (looking-at "UID: \\(.+\\)$")
-    (org-id-goto (match-string 1))))
+    (org-id-goto (org-caldav-trim-uid (match-string 1)))))
 
 ;; The following is taken from icalendar.el, written by Ulf Jasper.