From: Jani Nikula <jani@nikula.org>
To: Austin Clements <amdragon@MIT.EDU>, notmuch@notmuchmail.org
Subject: Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to
	g_mime_init()
In-Reply-To: <8738pcjet4.fsf@awakening.csail.mit.edu>
References: <1378839078-6298-1-git-send-email-jani@nikula.org>
	<8738pcjet4.fsf@awakening.csail.mit.edu>
User-Agent: Notmuch/0.16+74~g35e4af5 (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-pc-linux-gnu)
Date: Wed, 11 Sep 2013 20:40:40 +0300
Message-ID: <87vc27p887.fsf@nikula.org>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list

On Wed, 11 Sep 2013, Austin Clements <amdragon@MIT.EDU> wrote:
> LGTM in principle, though I'd like to see a test of some of the
> malformed RFC 2047 that this lets us decode.  Is there a summary
> somewhere of exactly what these workarounds enable?

Not that I know of; looking into gmime source it's mostly about encoded
words without surrounding space, or space within encoded words.

v2 now has known broken tests for known broken encodings...

> This isn't directly related to this patch, but is there a reason we
> g_mime_init in so many different places?  Both the CLI and
> notmuch_database_open I can understand because the CLI also uses GMime
> and should be sure it's initialized.  Maaaybe
> notmuch_message_file_get_header because notmuch_message_file
> theoretically independent of the database, even though I don't think
> it's possible to call into it without first calling
> notmuch_database_open.  But _notmuch_message_index_file?

I noted the same, but decided it's another patch, another time.


BR,
Jani.