On Mon, May 12 2014, Mark Walters wrote: > On Mon, 12 May 2014, David Edmondson <dme@dme.org> wrote: >> Use the message display code to generate message text to cite in >> replies. > > So this is the key change. I am trying to work out what the actual > changes are here: in your commit message for the test update 7/9 you say > that the old code only output the first part. My impression of the > deleted code is that that is not the case (but I don't grok cl very > well). The comment in the test change was intended only to refer to the content displayed in that specific test. You are correct that text from several parts could previously have been used (and all smashed together in a way that made it difficult to see the boundaries between the parts...). > I think the test change is because in show we do some content-type > guessing of application/octet-stream which the below doesn't do. > > But we may also have some things with mm-inlined-types as mentioned in > my earlier reply. Anyway if you can point out any other cases where it > is changed that would be great. message/rfc822 was the initial driver. If you now reply to a multipart/mixed that contains text/plain and message/rfc822 parts, you will see a significant difference. I'm not sure if you have it, but id:mailman.1.1399324386.31850.notmuch@notmuchmail.org was the message I used often when playing around. > If you go for a function deciding which parts to include then it might > be possible to have a midpoint where we are the same as before, and then > tweak the function to get whatever behaviour we think is best. That > might make it easy to see what is tidying/unification and what is > enhancement. I will look into that - it's a good suggestion, though it actually runs counter to: > Incidentally, thank you for splitting this series so finely: I did find > that made it a lot easier to review. Making the new code (which relies on the 'show' rendering code) behave just like the old code will involve adding a bunch of complication to this specific patch.