From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 19AD06DE0297 for ; Mon, 22 May 2017 03:32:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=0.010, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTkSv4OIY9Dw for ; Mon, 22 May 2017 03:32:46 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 66B896DE0173 for ; Mon, 22 May 2017 03:32:45 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1dCkct-0005UP-Iy; Mon, 22 May 2017 06:31:47 -0400 Received: (nullmailer pid 26127 invoked by uid 1000); Mon, 22 May 2017 10:32:40 -0000 From: David Bremner To: notmuch@notmuchmail.org, notmuch@freelists.org Subject: changing behaviour of notmuch show --part=1 X-List-To: notmuch Date: Mon, 22 May 2017 07:32:17 -0300 Message-ID: <878tlpyyfi.fsf@tethera.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 10:32:47 -0000 --=-=-= Content-Type: text/plain The current behaviour of "notmuch show --part=1 --raw" is somewhat peculiar. This is supposed to be the message body, but if the message is multipart, it also includes the headers. This seems to be a direct translation of an implimentation of quirk of gmime. In gmime 3.0 this quirk goes away, and the behaviour of notmuch consequently changes, unless we do something about it. I actually think the new behaviour makes more sense (you only get the headers with part=0). There seem to be several options 1) Bug-for-Bug-compatibility: Add special case code for gmime-3.0 to output headers. 2) Allow-varying-output: Consider the previous behaviour a bug, fixed by using gmime-3.0. This makes it hard for people to rely on, although how one relies on it currently since it varies by message is a mystery. 3) Fix the alleged bug: special case the output of the body with gmime-2.6 to avoid outputting headers. d --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlkivjEACgkQ8gKXHaSn niwPFgv9Fz8ifETWt+n+z1RdFzRpqUQqJMpJSICJg8u1lo5IjbLnDsvLPH2rhwNJ tkYr/gC4Tv6f77ngJExKOepMN7SrakKByj/i8ckEmEsNDHqaEsxS992zxEsAUJe1 Wbo4LFCNDPf07SVczcIbgo542Ljkp/ngVnBb+/jCBomVMn6p3615xCEmQhFdKhRn xsvN1BBdumAmuABT7LMu13n5gt0Ab20VpCxurySMNHfbX90ItnCkzfCHLKCGTGe6 zbjf5+uYVE8LoAtoelfrmWFz53w+4jXsVJyI1dDBhvefGa2vNybF+2Vjtw0sxag+ mEhmXYldCt2hOLQG1e+azoVm4MOYwW2EES5TVxBoXCMdsDSZRbt1t9wpUDVzoirk pc5TuNcxKZPgcQSRswQqS/ilNZZTATqEWWgtaUX0N/O4Q/eYIbnGg0J1ymrsQxnb DHJlbvKRqg+AP6W7Yqj9b+5Wfs6zbht5iTNZjPtASQ1RbZSRC16oHw6De9k7DHs0 mMsWBiVN =mLS8 -----END PGP SIGNATURE----- --=-=-=--