From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric S Fraga Subject: Re: org-caldav: New version with proper two-way sync Date: Thu, 17 Jan 2013 15:16:26 +1030 Message-ID: <87sj60ju1p.fsf@ucl.ac.uk> References: <87bocr4ej2.fsf@engster.org> <877gnd4wcv.fsf@ucl.ac.uk> <8738y14tv5.fsf@ucl.ac.uk> <87ip6w3iqe.fsf@engster.org> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:32929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tvhav-0000yY-LA for emacs-orgmode@gnu.org; Thu, 17 Jan 2013 00:00:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tvhat-0003L7-PH for emacs-orgmode@gnu.org; Thu, 17 Jan 2013 00:00:53 -0500 Received: from co9ehsobe001.messaging.microsoft.com ([207.46.163.24]:27251 helo=co9outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tvhat-0003KZ-Ck for emacs-orgmode@gnu.org; Thu, 17 Jan 2013 00:00:51 -0500 Received: from mail160-co9 (localhost [127.0.0.1]) by mail160-co9-R.bigfish.com (Postfix) with ESMTP id 43B742E0385 for ; Thu, 17 Jan 2013 04:45:42 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.232]) by mail160-co9.bigfish.com (Postfix) with ESMTP id B4BF7C0058 for ; Thu, 17 Jan 2013 04:45:40 +0000 (UTC) In-Reply-To: <87ip6w3iqe.fsf@engster.org> (David Engster's message of "Wed, 16 Jan 2013 22:45:13 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Emacs Org mode mailing list David Engster writes: > Eric S. Fraga writes:=20 >> I've tracked down the root of the various problems I have=20 >> encountered with the synchronisation. It all comes down to=20 >> character sets. I=20 >=20 >> have some entries that have UTF-8 characters that are not=20 >> present in ASCII, specifically accented characters and similar=20 >> (latin1, basically, but not exclusively). Any such entries=20 >> cause the synchronisation to fail.=20=20 >=20 > Could you post an example entry where this happens?=20 Sure but the problem does not appear to be what I had originally=20 thought. It turns out that all of my entries with non-ASCII=20 characters happened to be SEXP based entries, of this form: #+begin_src org * Test entries %%(diary-anniversary 1971 03 13) Somebody's=20 birthday (%d a=C3=B1os) #+end_src=20 (see the N TILDE character in the spanish word for years) The problem, however, seems related to the use SEXP entries and=20 not the character set. Having said this, my org diary file has had the encoding changed=20 out from under me so that all my UTF-8 characters have been=20 mangled. I've not quite figured out how this happened or when it=20 happened between yesterday and today. I cannot reproduce the=20 problem at the moment. This may be coincidental and have nothing=20 to do with org-caldav. However, it may be something to do with=20 using org-caldav in emacs -batch mode and whether files get loaded=20 in the same way. Still playing with this. =20 >> Resuming a failed synchronisation seems to forget to try to=20 >> bring in the external calendar entries into org?=20=20 >=20 > That happens last, so I wouldn't know why this would be skipped=20 > on resume. It's kinda hard to debug, though.=20 Okay. =20 >> The fact that descriptions are not synchronised for changed=20 >> entries is something I understand but probably need to think=20 >> about some more (in terms of default behaviour). Is there a=20 >> practical limitation on the size of the description entry that=20 >> could be synchronised? The default is 100 but would there be=20 >> any harm in having this 1, 2 or even 3 orders of magnitude=20 >> larger? Or even unlimited? Just wondering.=20 >=20 > I was wondering about that, too, but couldn't find any definite=20 > statements on the maximum length of the DESCRIPTION field. I=20 > only skimmed RFC 2445, though. Even if there is such a definite=20 > limit, I wouldn't count on servers to correctly implement=20 > that. I guess you just have to try what works.=20 Thanks. I'll stick to the default behaviour you have chosen; it's=20 good enough for most of my use cases and seems safest. =20 >> Anyway, with respect to my problems, would you please have a=20 >> look to see if you are assuming ASCII or similar and whether=20 >> there is anything you can do about this? I (and many others, I=20 >> assume) really do need to be able to work in UTF-8 at the very=20 >> least.=20 >=20 > I will look into that. I'm pretty sure this is fixable.=20 As mentioned above, I am now not sure if there are problems with=20 ASCII vs non-ASCII encodings. I will keep playing. =20 Thanks, eric --=20 : Eric S Fraga, GnuPG: 0xC89193D8FFFCF67D : in Emacs 24.3.50.1 and Org release_7.9.3d-826-gbe0d87