From: Eric S Fraga <e.fraga@ucl.ac.uk>
To: Emacs Org mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: org-caldav: New version with proper two-way sync
Date: Thu, 17 Jan 2013 15:16:26 +1030 [thread overview]
Message-ID: <87sj60ju1p.fsf@ucl.ac.uk> (raw)
In-Reply-To: <87ip6w3iqe.fsf@engster.org> (David Engster's message of "Wed, 16 Jan 2013 22:45:13 +0100")
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
next prev parent reply other threads:[~2013-01-17 5:00 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
2013-01-17 4:46 ` Eric S Fraga [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=87sj60ju1p.fsf@ucl.ac.uk \
--to=e.fraga@ucl.ac.uk \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).