Mark Walters <markwalters1009@gmail.com> writes: > 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 This is exactly what I have been wanting to suggest, but > mm-inline-override-types for notmuch's use. A defcustom would be > clutter, but a variable would mean anyone with unusual requirements I /do/ think it could be a defcustom to make it clear what notmuch is intentionally doing. It could be set to have "application/*" in it by default and then be unconditionally added to mm-inline-override-types in the notmuch-show defun (like patched now, only more properly user-defined with a safe default). If the user want to display whatever, she will set it to nil. Maybe it could even be called notmuch-show-mm-inline-override-types and sort under the custom Notmuch Show group. > could just setq it. > > What does anyone think? > > Best wishes > > Mark > > > -- Tomas Nordin | (The computing freedom explorer) GPG Key: AB09AF78