From: Mark Walters Date: Mon, 3 Feb 2014 08:04:21 +0000 (+0000) Subject: Re: [RFC] Content-Description when naming MIME parts in Emacs mode X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=b0749e15bda59ccdc08ff1d01b83a7a4e0a30418;p=notmuch-archives.git Re: [RFC] Content-Description when naming MIME parts in Emacs mode --- diff --git a/25/e7d0a2f4abdc7cdceb56a5c8598770235ac5c7 b/25/e7d0a2f4abdc7cdceb56a5c8598770235ac5c7 new file mode 100644 index 000000000..d6c4360ec --- /dev/null +++ b/25/e7d0a2f4abdc7cdceb56a5c8598770235ac5c7 @@ -0,0 +1,168 @@ +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 145D7431FBD + for ; Mon, 3 Feb 2014 00:07:19 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -1.098 +X-Spam-Level: +X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 + tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, + NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] 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 9sv9sIFC--O3 for ; + Mon, 3 Feb 2014 00:07:11 -0800 (PST) +Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id D68DE431FBC + for ; Mon, 3 Feb 2014 00:07:10 -0800 (PST) +Received: from smtp.qmul.ac.uk ([138.37.6.40]) + by mail2.qmul.ac.uk with esmtp (Exim 4.71) + (envelope-from ) + id 1WAEYO-0002cM-U3; Mon, 03 Feb 2014 08:07:06 +0000 +Received: from 94.196.253.24.threembb.co.uk ([94.196.253.24] helo=localhost) + by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71) + (envelope-from ) + id 1WAEXT-0002wC-FF; Mon, 03 Feb 2014 08:05:57 +0000 +From: Mark Walters +To: "W. Trevor King" , 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 +X-Sender-Host-Address: 94.196.253.24 +X-QM-Geographic: According to ripencc, + this message was delivered by a machine in Britain (UK) (GB). +X-QM-SPAM-Info: Sender has good ham record. :) +X-QM-Body-MD5: 83111c8d7eb1a4e51711a209d5baf09a (of first 20000 bytes) +X-SpamAssassin-Score: 0.0 +X-SpamAssassin-SpamBar: / +X-SpamAssassin-Report: The QM spam filters have analysed this message to + determine if it is + spam. We require at least 5.0 points to mark a message as spam. + This message scored 0.0 points. Summary of the scoring: + * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail + provider * (markwalters1009[at]gmail.com) +X-QM-Scan-Virus: ClamAV says the message is clean +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: Mon, 03 Feb 2014 08:07:19 -0000 + +On Sun, 02 Feb 2014, "W. Trevor King" 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