On Sun, 02 Feb 2014, "W. Trevor King" <wk...@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= mime-type "text/plain") (<= 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))) > > ;; Store the computed mime-type for later use (e.g. by attachment > handlers). > > 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 “genome” 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 —a̶x̶e̶— 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 + (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 > > -- > 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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch