From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 264F86DE1FA3 for ; Mon, 27 Feb 2017 12:32:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[AWL=0.065, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.211, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCUVkoGeRkix for ; Mon, 27 Feb 2017 12:32:27 -0800 (PST) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.66]) by arlo.cworth.org (Postfix) with ESMTPS id 9D3F56DE1FA2 for ; Mon, 27 Feb 2017 12:32:27 -0800 (PST) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 442CC20C0E for ; Mon, 27 Feb 2017 21:32:22 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3vXD0P737qz105R; Mon, 27 Feb 2017 21:32:21 +0100 (CET) Received: from tomas by debian with local (Exim 4.84_2) (envelope-from ) id 1ciS1e-00032U-1t; Mon, 27 Feb 2017 21:36:06 +0100 From: Tomas Nordin To: Mark Walters , David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH v2] emacs: show: stop display of application/* parts In-Reply-To: <8737f0qbl8.fsf@qmul.ac.uk> References: <1485596862-32326-1-git-send-email-markwalters1009@gmail.com> <87vasfhvg8.fsf@flaptop.tomnor.org> <87efz2ma7r.fsf@rocinante.cs.unb.ca> <8737f0qbl8.fsf@qmul.ac.uk> Date: Mon, 27 Feb 2017 21:36:06 +0100 Message-ID: <87shmz2wy1.fsf@debian.tompa.tv> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 20:32:29 -0000 Mark Walters 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