emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: David Engster <deng@randomsample.de>
To: Emacs Org mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: org-caldav: New version with proper two-way sync
Date: Wed, 16 Jan 2013 22:45:13 +0100	[thread overview]
Message-ID: <87ip6w3iqe.fsf@engster.org> (raw)
In-Reply-To: <8738y14tv5.fsf@ucl.ac.uk> (Eric S. Fraga's message of "Wed, 16 Jan 2013 15:17:10 +1030")

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?

> 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.

> 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.

> 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.


  reply	other threads:[~2013-01-16 21:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-14 21:53 org-caldav: New version with proper two-way sync David Engster
2013-01-14 22:29 ` Rasmus
2013-01-15 18:23   ` Vincent Beffara
2013-01-16 21:53     ` David Engster
2013-01-16  3:36 ` Eric S Fraga
2013-01-16  3:53 ` Eric S Fraga
2013-01-16  4:47   ` Eric S Fraga
2013-01-16 21:45     ` David Engster [this message]
2013-01-17  4:46       ` Eric S Fraga
2013-01-17  5:34         ` Eric S Fraga
2013-01-17  8:10         ` Detlef Steuer
2013-01-17  8:35           ` Eric S Fraga
2013-01-17  9:29             ` Detlef Steuer
2013-01-18  3:48               ` Eric S Fraga
2013-01-16  4:15 ` JBash
2013-01-16  9:47 ` Detlef Steuer
2013-01-16 21:35   ` David Engster
2013-01-17  8:12     ` Detlef Steuer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ip6w3iqe.fsf@engster.org \
    --to=deng@randomsample.de \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).