Re: org-caldav: New version with proper two-way sync

[Eric S Fraga <e.fraga@ucl.ac.uk>]

David Engster <deng@randomsample.de> writes:

> Eric S. Fraga writes: 
>> I've tracked down the root of the various problems I have 
>> encountered with the synchronisation.  It all comes down to 
>> character sets.  I 
> 
>> have some entries that have UTF-8 characters that are not 
>> present in ASCII, specifically accented characters and similar 
>> (latin1, basically, but not exclusively).  Any such entries 
>> cause the synchronisation to fail.  
> 
> Could you post an example entry where this happens? 

Sure but the problem does not appear to be what I had originally 
thought.  It turns out that all of my entries with non-ASCII 
characters happened to be SEXP based entries, of this form:

#+begin_src org
* Test entries %%(diary-anniversary 1971 03 13) Somebody's 
birthday (%d años) #+end_src 

(see the N TILDE character in the spanish word for years)

The problem, however, seems related to the use SEXP entries and 
not the character set.

Having said this, my org diary file has had the encoding changed 
out from under me so that all my UTF-8 characters have been 
mangled.  I've not quite figured out how this happened or when it 
happened between yesterday and today.  I cannot reproduce the 
problem at the moment.  This may be coincidental and have nothing 
to do with org-caldav.  However, it may be something to do with 
using org-caldav in emacs -batch mode and whether files get loaded 
in the same way.  Still playing with this.
 
>> Resuming a failed synchronisation seems to forget to try to 
>> bring in the external calendar entries into org?  
> 
> That happens last, so I wouldn't know why this would be skipped 
> on resume. It's kinda hard to debug, though. 

Okay.
 
>> The fact that descriptions are not synchronised for changed 
>> entries is something I understand but probably need to think 
>> about some more (in terms of default behaviour).  Is there a 
>> practical limitation on the size of the description entry that 
>> could be synchronised?  The default is 100 but would there be 
>> any harm in having this 1, 2 or even 3 orders of magnitude 
>> larger?  Or even unlimited?  Just wondering. 
> 
> I was wondering about that, too, but couldn't find any definite 
> statements on the maximum length of the DESCRIPTION field. I 
> only skimmed RFC 2445, though. Even if there is such a definite 
> limit, I wouldn't count on servers to correctly implement 
> that. I guess you just have to try what works. 

Thanks.  I'll stick to the default behaviour you have chosen; it's 
good enough for most of my use cases and seems safest.
 
>> Anyway, with respect to my problems, would you please have a 
>> look to see if you are assuming ASCII or similar and whether 
>> there is anything you can do about this?  I (and many others, I 
>> assume) really do need to be able to work in UTF-8 at the very 
>> least. 
> 
> I will look into that. I'm pretty sure this is fixable. 

As mentioned above, I am now not sure if there are problems with 
ASCII vs non-ASCII encodings.  I will keep playing.
 
Thanks,
eric
-- 
: Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D
: in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87