On Mon 2021-01-04 22:07:49 +0100, Jonas Bernoulli wrote:
> There are other places in the elisp code where the `:content-type' is
> assumed to be a string, so fixing it just here doesn't cut it.  To fix
> it for everyone, "notmuch show..." should probably take care of falling
> back to some sane default if the type cannot be determined.

the only two "sane defaults" would be either "text/plain" or
"application/octet-stream", but the circumstances in which they are
appropriate might differ.  e.g. a the top level of a message (or the top
level of a message/rfc822 subpart), the "sane default" would be
"text/plain" (because that's how messages by MIME-ignorant mailers look,
and they should still be readable text).  But a subpart without a
Content-Type designation should maybe default to
"application/octet-stream", or (even fancier) maybe a guess based on
other part headers, discovered filenames, or by sniffing content (yikes,
there be dragons).

All that said, i think fixing all the places in the elisp code is the
safer route, because the elisp code can't guarantee what the local
version of notmuch will do.  At the very least, if :content-type isn't a
string, notmuch-show shouldn't choke and break the rendering of the
thread.

So i think we should identify all the places where :content-type is
expected to be a string, and degrade gracefully if that is not how the
field is populated.

      --dkg