On Wed, 18 Jan 2012 23:00:15 +0400, Dmitry Kurochkin <[email protected]> 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).
pgp32c5YEsG44.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list [email protected] http://notmuchmail.org/mailman/listinfo/notmuch
