--- /dev/null
+Return-Path: <m.walters@qmul.ac.uk>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 145D7431FBD\r
+ for <notmuch@notmuchmail.org>; Mon, 3 Feb 2014 00:07:19 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.098\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
+ tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
+ NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id 9sv9sIFC--O3 for <notmuch@notmuchmail.org>;\r
+ Mon, 3 Feb 2014 00:07:11 -0800 (PST)\r
+Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id D68DE431FBC\r
+ for <notmuch@notmuchmail.org>; Mon, 3 Feb 2014 00:07:10 -0800 (PST)\r
+Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
+ by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1WAEYO-0002cM-U3; Mon, 03 Feb 2014 08:07:06 +0000\r
+Received: from 94.196.253.24.threembb.co.uk ([94.196.253.24] helo=localhost)\r
+ by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
+ (envelope-from <m.walters@qmul.ac.uk>)\r
+ id 1WAEXT-0002wC-FF; Mon, 03 Feb 2014 08:05:57 +0000\r
+From: Mark Walters <markwalters1009@gmail.com>\r
+To: "W. Trevor King" <wking@tremily.us>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC] Content-Description when naming MIME parts in Emacs mode\r
+In-Reply-To: <20140202204616.GD14197@odin.tremily.us>\r
+References: <20140202204616.GD14197@odin.tremily.us>\r
+User-Agent: Notmuch/0.15.2+484~gfb59956 (http://notmuchmail.org) Emacs/23.4.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Mon, 03 Feb 2014 08:04:21 +0000\r
+Message-ID: <877g9chbay.fsf@qmul.ac.uk>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+X-Sender-Host-Address: 94.196.253.24\r
+X-QM-Geographic: According to ripencc,\r
+ this message was delivered by a machine in Britain (UK) (GB).\r
+X-QM-SPAM-Info: Sender has good ham record. :)\r
+X-QM-Body-MD5: 83111c8d7eb1a4e51711a209d5baf09a (of first 20000 bytes)\r
+X-SpamAssassin-Score: 0.0\r
+X-SpamAssassin-SpamBar: /\r
+X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
+ determine if it is\r
+ spam. We require at least 5.0 points to mark a message as spam.\r
+ This message scored 0.0 points. Summary of the scoring: \r
+ * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
+ provider * (markwalters1009[at]gmail.com)\r
+X-QM-Scan-Virus: ClamAV says the message is clean\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Mon, 03 Feb 2014 08:07:19 -0000\r
+\r
+On Sun, 02 Feb 2014, "W. Trevor King" <wking@tremily.us> wrote:\r
+> On the rss2email list, Victor Orlikowski pointed out [1] that a number\r
+> of MUAs don't use the Subject header of attached message/rfc822 parts\r
+> to label multipart/digest subparts [2]. Instead, notmuch and several\r
+> other MUAs use the filename parameter [3] as a content hint [4].\r
+> Using the filename parameter seems more sane than diving into the\r
+> message/rfc822 part header, but that's still not what the filename\r
+> parameter was designed for. It makes more sense to me to use the\r
+> message/rfc822 part's Content-Description header [5,6], falling back\r
+> on the filename parameter if Content-Description isn't set.\r
+>\r
+> It's pretty easy to patch notmuch-show-insert-bodypart to do this:\r
+>\r
+> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el\r
+> index 1ac80ca..485c7d1 100644\r
+> --- a/emacs/notmuch-show.el\r
+> +++ b/emacs/notmuch-show.el\r
+> @@ -874,13 +874,16 @@ useful for quoting in replies)."\r
+> content-type))\r
+> (nth (plist-get part :id))\r
+> (beg (point))\r
+> + (name (if (plist-get part :content-description)\r
+> + (plist-get part :content-description)\r
+> + (plist-get part :filename)))\r
+> ;; Hide the part initially if HIDE is t.\r
+> (show-part (not (equal hide t)))\r
+> ;; We omit the part button for the first (or only) part if\r
+> ;; this is text/plain, or HIDE is 'no-buttons.\r
+> (button (unless (or (equal hide 'no-buttons)\r
+> (and (string=3D mime-type "text/plain") (<=\r
+=3D nth 1)))\r
+> - (notmuch-show-insert-part-header nth mime-type conten=\r
+t-type (plist-get part :filename))))\r
+> + (notmuch-show-insert-part-header nth mime-type conten=\r
+t-type name)))\r
+> (content-beg (point)))\r
+>=20=20\r
+> ;; Store the computed mime-type for later use (e.g. by attachment ha=\r
+ndlers).\r
+>\r
+> But that doesn't work, because :content-description doesn't exist in\r
+> the part plist. I've looked through the source for a bit and can't\r
+> figure out where that part plist is coming from. Is it loaded from\r
+> notmuch output in notmuch-show-build-buffer? I assume that\r
+> information comes from the index, in which case I'd need to tweak\r
+> _index_mime_part in lib/index.cc to add the description. Indexing\r
+> descriptions seems like a generally useful thing, even outside of my\r
+> digest usecase (e.g. search image/jpeg attachements with =E2=80=9Cgenome=\r
+=E2=80=9D in\r
+> their description [6]). However, adding a field to the schema is more\r
+> invasive than changing the Emacs mode's attachment formatting; I\r
+> thought I should check in here for feedback and advice before wading\r
+> in with my =E2=80=94a=CC=B6x=CC=B6e=CC=B6=E2=80=94 scalpel ;).\r
+\r
+I think notmuch-show.c gets most of the header and related information\r
+directly from the mail file not from the database directly. I think we\r
+use gmime for that parsing so adding an extra output pair for\r
+content-description there should be sufficient. (This is lines 655-700\r
+or so notmuch-show.c)\r
+\r
+I think the emacs side should be roughly as above: we would need to\r
+check that the default filename offered when saving is still\r
+correct. Stylistically I think=20\r
++ (name (or (plist-get part :content-description)\r
++ (plist-get part :filename)))\r
+\r
+is a little nicer.\r
+\r
+I think that the above all looks like a sensible change to notmuch so I\r
+would expect something like the above to be acceptable in mainline (but\r
+obviously that is not my call!)\r
+\r
+Best wishes\r
+\r
+Mark\r
+\r
+>\r
+> Thoughs?\r
+> Trevor\r
+>\r
+> [1]: http://article.gmane.org/gmane.mail.rss2email/211\r
+> [2]: Digests: http://tools.ietf.org/html/rfc2046#section-5.1.5\r
+> [3]: Filename: http://tools.ietf.org/search/rfc2183#section-2.3\r
+> [4]: Filename hint to notmuch-show-insert-part-header:\r
+> http://git.notmuchmail.org/git/notmuch/blob/HEAD:/emacs/notmuch-show=\r
+.el#l883\r
+> [5]: Content-Desciption:\r
+> http://tools.ietf.org/html/rfc2045#section-8\r
+> [6]: Content-Description examples:\r
+> http://tools.ietf.org/html/rfc2183#section-3\r
+>\r
+> --=20\r
+> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).\r
+> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy\r
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r
projects / notmuch-archives.git / commitdiff