On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> So a message like this:
> 
> A└┬╴multipart/signed 355339 bytes
> B ├┬╴multipart/mixed 353462 bytes
> C │├╴text/plain 235 bytes
> D │└╴image/jpeg attachment [foo.jpg] 352752 bytes
> E └╴application/pgp-signature attachment [signature.asc] 1030 bytes

I tried creating a message like that but mine came out slightly
differently:

> A└┬╴multipart/mixed
> B ├┬╴multipart/signed
> C │├╴text/plain
> D │└╴application/pgp-signature
> E └╴application/octet-stream

I'll have to learn better how to control the emacs mail composer in
order to understand how to get signatures to cover attachments if I want
to do that kind of thing.

> would come out with three parts:
> 
>  1) C
>  2) D
>  3) E

That is indeed the behavior I see with master (for both text and json
output).

> the new code assigns this message to 5 parts:
> 
>  1) A
>  2) B
>  3) C
>  4) D
>  5) E

Interestingly, this is not quite the behavior I get (with commit
373f352). With --format=text I'm now seeing:

2) C
3) D
4) E

and with --format=json I'm seeing (I think this structure is right):

1) A
  3) B
    5) C
    7) D
  9) E

So that explains some of my confusion. The behavioral change of this
commit is really only impacting the json format, and not the text. That
wasn't clear from the commit message (and I had only been doing my
testing with the text backend).

This seems to be justifying my fears about the code duplication---the
two code paths are already divergent, (which means that things like
notmuch part-number identifiers cannot be used between the different
formats). I'd like to fix that by preventing the code duplication.

Also, both paths seem to be suffering from some excess part-number
incrementing somewhere.

All of this should be easy to get right with a careful test case or two.

-Carl