Date: Sun, 2 Feb 2014 12:46:17 -0800
From: "W. Trevor King" <wking@tremily.us>
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)
Precedence: list


--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--