Hi! As discussed on irc, if notmuch stores header values in utf8, its safe to decode them to unicode instances here. best, /p On Mon, Jul 11, 2011 at 08:03:38AM -0700, Carl Worth wrote: > On Mon, 11 Jul 2011 16:04:17 +0200, Sebastian Spaeth <Sebastian@SSpaeth.de> 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. > > > > 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. > > -Carl > > -- > carl.d.worth@intel.com > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch