On Mon, Feb 27 2017, Mark Walters <markwalters1009@gmail.com> wrote:

> Hi
>
>>> But what will we do if the user has not customized it because she
>>> /wants/ to display all possible things inline. I have not seen that this
>>> patch is merged into master, and probably, when I have learned about
>>> this variable, I think maybe it's better not to do it in the notmuch
>>> code.
>
> Well they can set mm-inline-override-types to
> "non-existent/type". Rather a kludge I agree.
>
>> The problem is that the gnus default is somehow unsafe, and causes bad
>> behaviour for people receiving large attachments.
>
> I agree with this and do think we should block this by default. In
> particular, gnus/mm stuff doesn't even check for the existence of unzip
> before running it on zip attachments so on my machines which don't have
> unzip I get a bodypart insertion error.
>
> One alternative would be to add a variable
> notmuch-mm-inline-override-types which would combine or replace
> mm-inline-override-types for notmuch's use. A defcustom would be
> clutter, but a variable would mean anyone with unusual requirements
> could just setq it.
>
> What does anyone think?

patch is pushed, and that is good (i did not read the above content, so if
I am not answering the right guestion, then ignore this ;)

>
> Best wishes
>
> Mark
>
>
>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch