Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id CC020431FD0 for ; Mon, 11 Jul 2011 08:03:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.01 X-Spam-Level: X-Spam-Status: No, score=0.01 tagged_above=-999 required=5 tests=[T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ityJkvnzG5H for ; Mon, 11 Jul 2011 08:03:46 -0700 (PDT) Received: from arlo.cworth.org (arlo.cworth.org [50.43.72.2]) by olra.theworths.org (Postfix) with ESMTP id 2AD39431FB6 for ; Mon, 11 Jul 2011 08:03:46 -0700 (PDT) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id BE75B29A551; Mon, 11 Jul 2011 08:03:44 -0700 (PDT) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id ABF35254147; Mon, 11 Jul 2011 08:03:44 -0700 (PDT) From: Carl Worth To: Sebastian Spaeth , Notmuch developer list Subject: Re: Encodings In-Reply-To: <87zkkkx6am.fsf@SSpaeth.de> References: <87zkkkx6am.fsf@SSpaeth.de> User-Agent: Notmuch/0.6 (http://notmuchmail.org) Emacs/23.3.1 (i486-pc-linux-gnu) Date: Mon, 11 Jul 2011 08:03:38 -0700 Message-ID: <87box0lv05.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 15:03:46 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth = wrote: > The answer is that things are very implicit. notmuch.h speaks of > strings but never mentions encodings Much of this was intentional on my part. For example, I intentionally avoided restrictions on what could be stored as a tag in the database, (other than the terminating character implied by "string" of course). > So, can be document what encoding we are expected to pass in the various > APIs Yes, let's clarify documentation wherever we need to. > For some of the stuff we read directly from the files, eg > arbitrary headers, we can probably be least sure The headers should be decoded to utf-8, (via g_mime_utils_header_decode_text), before being stored in the database. > but are e.g. the returned tags always utf-8? No. The tag data is returned exactly as the user presented it. > I would love to make the python bindings use unicode() instances in > cases where we can be sure to actually receive utf-8 encoded strings. >=20 > Encodings make my brain hurt. Unfortunately one cannot simply ignore > them. I think a lot of the pain here is due to some bad design decisions in python itself. Of course, my saying that doesn't make things any easier for you. But do tell me what more we can do to clarify behavior or documentation. =2DCarl =2D-=20 carl.d.worth@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk4bEMoACgkQ6JDdNq8qSWg8oACeKTnWC2O8P95anL+EL8oKpHuL qxAAoJMTieU15udi6b2wvSSszOKfnex5 =a4mc -----END PGP SIGNATURE----- --=-=-=--