Received-SPF: pass (google.com: domain of pieter@praet.org designates
	10.180.99.100 as permitted sender) client-ip=10.180.99.100; 
From: Pieter Praet <pieter@praet.org>
To: David Bremner <david@tethera.net>
Subject: Re: [PATCH v6 1/3] emacs: `notmuch-show-get-message-id': optionally
	return Message-Id sans prefix
In-Reply-To: <87399tbzmx.fsf@zancas.localnet>
References: <1327397873-20596-1-git-send-email-dme@dme.org>
	<1329684627-10708-1-git-send-email-pieter@praet.org>
	<1329684627-10708-2-git-send-email-pieter@praet.org>
	<87ehtjj7s6.fsf@zancas.localnet> <87hayaol8b.fsf@praet.org>
	<87399tbzmx.fsf@zancas.localnet>
User-Agent: Notmuch/0.11.1+210~g6afc43e (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Thu, 01 Mar 2012 18:12:12 +0100
Message-ID: <87obsgmej7.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Notmuch Mail <notmuch@notmuchmail.org>
Precedence: list

On Wed, 29 Feb 2012 08:19:34 -0400, David Bremner <david@tethera.net> wrote:
> On Tue, 28 Feb 2012 19:40:04 +0100, Pieter Praet <pieter@praet.org> wrote:
> > 
> > Though I couldn't help but notice (it's a curse...) that patch #3
> > seems to have gained an extra space in its commit message subject:
> > 
> >   Original (id:"1329684627-10708-4-git-send-email-pieter@praet.org"):
> >     emacs: add `notmuch-show-stash-mlarchive-link{,-and-go}'
> >                                                   ^
> 
> I don't have any applypatch-msg hook. I am using 
>   "notmuch show --format=raw $messageid | git am -" to
> apply the patch.  
> 
> I looked at the file on disk, and something is wrapping the subject
> there.  Perhaps somebody's unwrapping code is buggy? I'm not sure what's
> at fault here; [...]

TL;DR:  Doesn't seem like there's much we can do about it...


According to RFC 2822 section 2.2.3 [1], header fields should be folded
by inserting a CRLF right before the last whitespace char before the
line exceeds 78 characters, and when a field contains comma-separated
values (which is somewhat applicable in this case), it should be folded
by inserting a CRLF right after a comma.

Now, the issue is that unfolding is accomplished by simply removing any
CRLF that is immediately followed by a whitespace char:

If the subject headers of those patches were folded by simply inserting
a CRLF, they couldn't possibly be unfolded again as there wouldn't be a
whitespace char right after the CRLF, so Mailman seems to have helpfully
inserted a tab...


Here's one of those patches at a number of archives:

- http://notmuchmail.org/pipermail/notmuch/2012/009575.html
- http://mid.gmane.org/1329684627-10708-4-git-send-email-pieter@praet.org
- http://mail-archive.com/search?l=mid&q=1329684627-10708-4-git-send-email-pieter@praet.org

As you can see (in the source of those pages), both Pipermail and Gmane
unfold the subject header by simply removing the line break, and at The
Mail Archive, the tab is also replaced by a space.  I assume the latter
also happens in gmime ?


So, I guess I'll just have to learn to live with it... :)


> [...] maybe you could experiment with applying the the patches
> from the list and let me know if e.g. going from files is better than
> using "notmuch show --format=raw".
>

Based on my (admittedly very superficial) analysis of the problem,
that won't do us any good wrt this issue, unfortunately...

But it *would* buy us a (slight) performance increase, so if/when my
patch to `notmuch-show-mapc' [2] goes in, we might want to consider
making `notmuch-show-pipe-message' use `notmuch-show-get-filename'
instead of `notmuch-show-get-message-{id,ids-for-open-messages}'.


> d
> 
> 


Peace

-- 
Pieter

[1] http://tools.ietf.org/html/rfc2822.html#section-2.2.3
[2] id:"1330122640-18895-5-git-send-email-pieter@praet.org"