Re: [PATCH v2] emacs: show: stop display of application/* parts

[Tomi Ollila]

On Mon, Feb 27 2017, Mark Walters  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
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] emacs: show: stop display of application/* parts

[Mark Walters]

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?

Best wishes

Mark



___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] emacs: show: stop display of application/* parts

[David Bremner]

Tomas Nordin  writes:

> Mark Walters  writes:
>
>> Gnus seems to display application/zip and application/tar by
>> default. This doesn't seem desirable so we override it.
>>
>> We only override if the user has not customized
>> mm-inline-override-types themselves.
>
> 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.

The problem is that the gnus default is somehow unsafe, and causes bad
behaviour for people receiving large attachments.

d
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] emacs: show: stop display of application/* parts

[Tomas Nordin]

Mark Walters  writes:

> Gnus seems to display application/zip and application/tar by
> default. This doesn't seem desirable so we override it.
>
> We only override if the user has not customized
> mm-inline-override-types themselves.

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.

I wrote this on on the wiki (on my machine). Is it maybe an option to
have it written down there so it is spoken out, and can be linked to at
next complaint. What do you think, should I push it?

I inserted this as a new level 2 heading under the

Controlling external handlers for attachements

heading. Is that bad? Maybe it breaks links...

1 file changed, 19 insertions(+)
emacstips.mdwn | 19 +++

modified   emacstips.mdwn
@@ -26,6 +26,25 @@ adding a .mailcap file in your home directory. Here is an 
example:
 application/pdf; /usr/bin/mupdf %s; test=test "$DISPLAY" != ""; 
description=Portable Document Format; nametemplate=%s.pdf
 application/x-pdf; /usr/bin/mupdf %s; test=test "$DISPLAY" != ""; 
description=Portable Document Format; nametemplate=%s.pdf
 
+## Overriding inline display of certain attachments
+
+If you are annoyed by notmuch showing large attachments like zip files
+with images, you can override the behavior by setting the
+mm-inline-override-types variable like this:
+
+(setq mm-inline-override-types
+(cons "application/zip" mm-inline-override-types))
+
+This will prevent the default display of the mime types specified. If
+you would like to make sure that *no* application-ish attachments
+tries to be displayed, then set the variable like this:
+
+(setq mm-inline-override-types
+(cons "application/*" mm-inline-override-types))
+
+Do this in any file that loads when emacs load, like in your `.emacs`
+or `.notmuch` file. Also note that this is an emacs user option.
+
 ## Overwriting the sender address
 
 If you want to always use the same sender address, then the following

Happy mailing
--
Tomas
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2] emacs: show: stop display of application/* parts

[Mark Walters]

Gnus seems to display application/zip and application/tar by
default. This doesn't seem desirable so we override it.

We only override if the user has not customized
mm-inline-override-types themselves.
---

I think this fixes all the bugs (and typos). Thanks to Tomas and Tomi
for finding and verifying the correct way to get the default value of
a defcustom variable.

It's only lightly tested but seems to work.

Best wishes

Mark



emacs/notmuch-show.el | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 364004b..c670160 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1227,7 +1227,15 @@ matched."
   (interactive "sNotmuch show: \nP")
   (let ((buffer-name (generate-new-buffer-name
  (or buffer-name
- (concat "*notmuch-" thread-id "*")
+ (concat "*notmuch-" thread-id "*"
+   ;; We override mm-inline-override-types to stop application/*
+   ;; parts from being displayed unless the user has customized
+   ;; it themselves.
+   (mm-inline-override-types
+(if (equal mm-inline-override-types
+   (eval (car (get 'mm-inline-override-types 
'standard-value
+(cons "application/*" mm-inline-override-types)
+  mm-inline-override-types)))
 (switch-to-buffer (get-buffer-create buffer-name))
 ;; No need to track undo information for this buffer.
 (setq buffer-undo-list t)
-- 
2.1.4

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch