emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric S Fraga
Subject: Re: [O] org-caldav: New version with proper two-way sync
Date: Thu, 17 Jan 2013 15:16:26 +1030
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux)

David Engster <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]