From: W. Trevor King Date: Sun, 2 Feb 2014 20:46:17 +0000 (+1600) Subject: [RFC] Content-Description when naming MIME parts in Emacs mode X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=f62e11d0175c5644665ad8eb23bae9c1d651b2f9;p=notmuch-archives.git [RFC] Content-Description when naming MIME parts in Emacs mode --- diff --git a/9c/b07d4bb295350003f2d01529fecbd6ab8f8046 b/9c/b07d4bb295350003f2d01529fecbd6ab8f8046 new file mode 100644 index 000000000..32048627e --- /dev/null +++ b/9c/b07d4bb295350003f2d01529fecbd6ab8f8046 @@ -0,0 +1,174 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id A6276431FBD + for ; Sun, 2 Feb 2014 12:54:39 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.1 +X-Spam-Level: +X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 + tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, + RCVD_IN_DNSWL_NONE=-0.0001] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Qnf8rC7eOq0n for ; + Sun, 2 Feb 2014 12:54:31 -0800 (PST) +X-Greylist: delayed 489 seconds by postgrey-1.32 at olra; + Sun, 02 Feb 2014 12:54:31 PST +Received: from qmta02.westchester.pa.mail.comcast.net + (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) + by olra.theworths.org (Postfix) with ESMTP id 54819431FBC + for ; Sun, 2 Feb 2014 12:54:31 -0800 (PST) +Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) + by qmta02.westchester.pa.mail.comcast.net with comcast + id MXyj1n00516LCl051YmLTS; Sun, 02 Feb 2014 20:46:20 +0000 +Received: from odin.tremily.us ([24.18.63.50]) + by omta06.westchester.pa.mail.comcast.net with comcast + id MYmK1n00E152l3L3SYmKoc; Sun, 02 Feb 2014 20:46:20 +0000 +Received: by odin.tremily.us (Postfix, from userid 1000) + id 8EB50FB067C; Sun, 2 Feb 2014 12:46:17 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tremily.us; s=odin; + t=1391373977; bh=XcX8eC78IwtVg8Uji22aGMQAHvvr5LgCO8tU9GKnE20=; + h=Date:From:To:Subject; + b=ery8RxIRh+9FBbfllTt5CqvJMIo+ADrcT7dZZSQ7ET6LSB3wwF8b2ngL5CHjb8wm6 + tfupHdoBsjZp79Noq6arMwRB7dV8CCVwJbWCDI9ac3xinnz1vN0cVBjri5G+a9xEYQ + uy9nF+F8O+S3H9HQf956TU1pcbBJci2SKQg+F0Ok= +Date: Sun, 2 Feb 2014 12:46:17 -0800 +From: "W. Trevor King" +To: notmuch@notmuchmail.org +Subject: [RFC] Content-Description when naming MIME parts in Emacs mode +Message-ID: <20140202204616.GD14197@odin.tremily.us> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha1; + protocol="application/pgp-signature"; boundary="cHOhevsz5PKyTXvv" +Content-Disposition: inline +OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8; + url=http://tremily.us/pubkey.txt +User-Agent: Mutt/1.5.22 (2013-10-16) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; + s=q20121106; t=1391373980; + bh=kVNMZCpAdEgUE+AJlaP8p0JpEXDQHZN3PvccdLc4bZ0=; + h=Received:Received:Received:Date:From:To:Subject:Message-ID: + MIME-Version:Content-Type; + b=HpfG4Ip/7T77DeaFBu04M6DpRrdfCWnZouobboccTHVIx1qYN/Jl+jKooRXC8ptuS + /WF3D62ZU1hWkjySxTbIF/dn2tb9JxegyuH32NVzvx0HJnTFAAkPApRMs2ZM/4wcat + kTXUN8R2LQ9Utzl6Ix7Qr83s3cmmbPo2PsuPzKqx7mTAGLjaHOcvqlHEatq7wNMk1S + NTxM1gOvIWH3IPxo/OT/oYrzJbJPJUiXWJrsdAxVxCrtVc+S83If0/hlICGLo/A5aT + PMTMCXVwxzT2kfY+PKyyTh4/9QRZ6JyNySw9I7FQCv0MDXMHPL30CmhsoWtN4Tof1I + Hasr4rmS8blfg== +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +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: Sun, 02 Feb 2014 20:54:39 -0000 + + +--cHOhevsz5PKyTXvv +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On the rss2email list, Victor Orlikowski pointed out [1] that a number +of MUAs don't use the Subject header of attached message/rfc822 parts +to label multipart/digest subparts [2]. Instead, notmuch and several +other MUAs use the filename parameter [3] as a content hint [4]. +Using the filename parameter seems more sane than diving into the +message/rfc822 part header, but that's still not what the filename +parameter was designed for. It makes more sense to me to use the +message/rfc822 part's Content-Description header [5,6], falling back +on the filename parameter if Content-Description isn't set. + +It's pretty easy to patch notmuch-show-insert-bodypart to do this: + +diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el +index 1ac80ca..485c7d1 100644 +--- a/emacs/notmuch-show.el ++++ b/emacs/notmuch-show.el +@@ -874,13 +874,16 @@ useful for quoting in replies)." + content-type)) + (nth (plist-get part :id)) + (beg (point)) ++ (name (if (plist-get part :content-description) ++ (plist-get part :content-description) ++ (plist-get part :filename))) + ;; Hide the part initially if HIDE is t. + (show-part (not (equal hide t))) + ;; We omit the part button for the first (or only) part if + ;; this is text/plain, or HIDE is 'no-buttons. + (button (unless (or (equal hide 'no-buttons) + (and (string=3D mime-type "text/plain") (<=3D= + nth 1))) +- (notmuch-show-insert-part-header nth mime-type content-= +type (plist-get part :filename)))) ++ (notmuch-show-insert-part-header nth mime-type content-= +type name))) + (content-beg (point))) +=20 + ;; Store the computed mime-type for later use (e.g. by attachment hand= +lers). + +But that doesn't work, because :content-description doesn't exist in +the part plist. I've looked through the source for a bit and can't +figure out where that part plist is coming from. Is it loaded from +notmuch output in notmuch-show-build-buffer? I assume that +information comes from the index, in which case I'd need to tweak +_index_mime_part in lib/index.cc to add the description. Indexing +descriptions seems like a generally useful thing, even outside of my +digest usecase (e.g. search image/jpeg attachements with =E2=80=9Cgenome=E2= +=80=9D in +their description [6]). However, adding a field to the schema is more +invasive than changing the Emacs mode's attachment formatting; I +thought I should check in here for feedback and advice before wading +in with my =E2=80=94a=CC=B6x=CC=B6e=CC=B6=E2=80=94 scalpel ;). + +Thoughs? +Trevor + +[1]: http://article.gmane.org/gmane.mail.rss2email/211 +[2]: Digests: http://tools.ietf.org/html/rfc2046#section-5.1.5 +[3]: Filename: http://tools.ietf.org/search/rfc2183#section-2.3 +[4]: Filename hint to notmuch-show-insert-part-header: + http://git.notmuchmail.org/git/notmuch/blob/HEAD:/emacs/notmuch-show.e= +l#l883 +[5]: Content-Desciption: + http://tools.ietf.org/html/rfc2045#section-8 +[6]: Content-Description examples: + http://tools.ietf.org/html/rfc2183#section-3 + +--=20 +This email may be signed or encrypted with GnuPG (http://www.gnupg.org). +For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy + +--cHOhevsz5PKyTXvv +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2.0.22 (GNU/Linux) + +iQIcBAEBAgAGBQJS7q6UAAoJEKKfehoaNkbtDloQAKqHKmui8Ron0MtQSKgnDHMj +NT4jftGDWGLtunq+1zr5+IIglzEQ88Z+Q2+2NpHq1IQYKfI1NPnScVGoCjJucv1O +pB9TKxsWOPptVE8s8A2W50Hb01pVzXNt9oN5VsPzZ8GkjaLu3UL3E/UrY1mqGP92 +ChBWU/lMPED4we9KQAifFV4zM88c3gzHVQKCXHRRRDZ0FpjDWB7ZK5sqtfNXgmU5 +pnwBgxpE2OK4xTq3ZuttmsIPcxO7l0p6WD93kCxQRNcC/JjRyms5an+n4hv72Wop +ulvCwGqm1kO6x7NMAqSCi4pDb8If8b9K39D6AnKXo9OKORnVrIdWS/y9pD8mI0nP +3VRmcWVCezSutP5kod4022kd1GxmziHNV4a2MJ0rL8AICAd5ufiISXC7bVWqLppf +RZm35nv51wNHGoouJgnVPaQFNlfNaZE6mlt+3jYc4dyLrU3UDyZ0bJ5w3qrJDLfD +uud8mkHFx7TvssmgY+Qf8+OR14GI2MSvfabINhIXjIhrhFjxrQEKEtRpr1+WOwBQ +l5gtPJEpigqmtARbzEcXcv964VGF9PsfJRNps48ZqEoyGLbTOTVu28qySouoaULR +gmZVvSI18DB3cKIAgV/njolobn9MMwv5YR9VkKoLbaJYeNX0j4Er1Lp5ubXTfqvz +tKNTxGYhjyYhphGxNPdo +=Ppvq +-----END PGP SIGNATURE----- + +--cHOhevsz5PKyTXvv--