From: Mark Walters <markwalters1009@gmail.com>
To: "W. Trevor King" <wking@tremily.us>, notmuch@notmuchmail.org
Subject: Re: [RFC] Content-Description when naming MIME parts in Emacs mode
In-Reply-To: <20140202204616.GD14197@odin.tremily.us>
References: <20140202204616.GD14197@odin.tremily.us>
User-Agent: Notmuch/0.15.2+484~gfb59956 (http://notmuchmail.org) Emacs/23.4.1
	(x86_64-pc-linux-gnu)
Date: Mon, 03 Feb 2014 08:04:21 +0000
Message-ID: <877g9chbay.fsf@qmul.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list

On Sun, 02 Feb 2014, "W. Trevor King" <wking@tremily.us> wrote:
> 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 conten=
t-type (plist-get part :filename))))
> +                   (notmuch-show-insert-part-header nth mime-type conten=
t-type name)))
>           (content-beg (point)))
>=20=20
>      ;; Store the computed mime-type for later use (e.g. by attachment ha=
ndlers).
>
> 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 ;).

I think notmuch-show.c gets most of the header and related information
directly from the mail file not from the database directly. I think we
use gmime for that parsing so adding an extra output pair for
content-description there should be sufficient. (This is lines 655-700
or so notmuch-show.c)

I think the emacs side should be roughly as above: we would need to
check that the default filename offered when saving is still
correct. Stylistically I think=20
+         (name (or (plist-get part :content-description)
+                   (plist-get part :filename)))

is a little nicer.

I think that the above all looks like a sensible change to notmuch so I
would expect something like the above to be acceptable in mainline (but
obviously that is not my call!)

Best wishes

Mark

>
> 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=
.el#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
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch