On Wed, 18 Jan 2012 23:00:15 +0400, Dmitry Kurochkin <dmitry.kurochkin at gmail.com> wrote: > > That would allow a sane default (("image/*" "text/*") perhaps), but also > > allow more to be added to that list (or some to be removed), either by > > code that detected the (in)ability to render it or the user. > > Perhaps there is such a list in mm already?
There's a function which does almost exactly this - `mm-inlinable-p'. It has a list of types and tests, `mm-inline-media-tests'. Some of those tests require access to the part content to decide if the part is inlinable. Many of them don't. The image/jpeg test _does_ want access to the part content. We're already using this function, of course. `mm-inlined-p' is the corresponding "does the user want this part inlined" test. It's much simpler and never looks at the part content. Currently we merge those tests into one: (if (and (mm-inlinable-p handle) (mm-inlined-p handle)) and have acquired part content either before or after the combined test. Perhaps we could test `mm-inlined-p' first, then insert the content, then test `mm-inlinable-p'? That way we would not acquire the content for parts for which the user (or code) has selected not to inline the content. Currently `mm-inlined-p' suggests that the following should be inlined by default: "image/.*" "text/.*" "message/delivery-status" "message/rfc822" "message/partial" "message/external-body" "application/emacs-lisp" "application/x-emacs-lisp" "application/pgp-signature" "application/x-pkcs7-signature" "application/pkcs7-signature" "application/x-pkcs7-mime" "application/pkcs7-mime" These are the only types for which we'd acquire the part content for examination by `mm-inlinable-p' (by default). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120119/c5220a9f/attachment.pgp>