From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 7FA78431FBC for ; Wed, 18 Jan 2012 11:35:19 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwZ2gLqcFGyK for ; Wed, 18 Jan 2012 11:35:17 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by olra.theworths.org (Postfix) with ESMTP id 3809A431FAE for ; Wed, 18 Jan 2012 11:35:17 -0800 (PST) X-AuditID: 1209190d-b7fbf6d0000008ba-76-4f171ef4914b Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 7C.0B.02234.4FE171F4; Wed, 18 Jan 2012 14:35:16 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id q0IJZGGE003081; Wed, 18 Jan 2012 14:35:16 -0500 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q0IJZFei021857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 18 Jan 2012 14:35:16 -0500 (EST) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1RnbHh-0001b5-1d; Wed, 18 Jan 2012 14:35:01 -0500 Date: Wed, 18 Jan 2012 14:35:01 -0500 From: Austin Clements To: Dmitry Kurochkin Subject: Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks. Message-ID: <20120118193501.GG16740@mit.edu> References: <1326907993-11054-1-git-send-email-dme@dme.org> <1326908371-11949-1-git-send-email-dme@dme.org> <877h0o99aj.fsf@gmail.com> <874nvs96ps.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874nvs96ps.fsf@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT0f0iJ+5vsLfJ3GLfnS1MFle39rNb XL85k9mB2WPX879MHjtn3WX3eLbqFnMAcxSXTUpqTmZZapG+XQJXxqbbn1gLpnNXPF57h7mB 8Q1HFyMnh4SAicTJm1eZIWwxiQv31rN1MXJxCAnsY5SYOeEbK4SzgVFi5dyFLBDOSSaJ37dW QTlLGCXWf1sDVMbBwSKgKnF1fjzIKDYBDYlt+5czgtgiAoYSty6+AlvBLGAlcfHZHnYQW1gg SmJ6Uw8TiM0roCPx5cEeJoiZNxklph/sgkoISpyc+YQFollL4sa/l0wgu5gFpCWW/wN7gVNA XeLCqgtg5aICKhJTTm5jm8AoNAtJ9ywk3bMQuhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3S NdLLzSzRS00p3cQICnZOSd4djO8OKh1iFOBgVOLhjRQR9xdiTSwrrsw9xCjJwaQkyjtPFijE l5SfUpmRWJwRX1Sak1p8iFGCg1lJhPcLH1CONyWxsiq1KB8mJc3BoiTOq6r1zk9IID2xJDU7 NbUgtQgmK8PBoSTBqwKMaiHBotT01Iq0zJwShDQTByfIcB6g4TUgi3mLCxJzizPTIfKnGBWl xHn5QJoFQBIZpXlwvbBk9IpRHOgVYd7zIO08wEQG1/0KaDAT0GCPJjGQwSWJCCmpBsbti+ar LOff7mNtnm6x643x0ulfrE7GbJrbMcc/Lc+Xecbsv7Ou80o6X5fLqJ30QMZRZbna+wz2mzO5 rhm26r5dJuo9e336TJEtVTxme+3y52SUmucEaN+WTD+79MOioGum+Wb+kuuN5Nd/WMb0IHmT 5ZbszU079mwvYL2qZNBkzW6tsrHzpKsSS3FGoqEWc1FxIgCYA0ZEIQMAAA== Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 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: Wed, 18 Jan 2012 19:35:19 -0000 Quoth Dmitry Kurochkin on Jan 18 at 11:00 pm: > On Wed, 18 Jan 2012 18:30:36 +0000, David Edmondson wrote: > > On Wed, 18 Jan 2012 22:04:36 +0400, Dmitry Kurochkin wrote: > > > On Wed, 18 Jan 2012 17:39:31 +0000, David Edmondson wrote: > > > > The `mm-inlinable-p' and `mm-inlined-p' functions work better if they > > > > have access to the data of the relevant part, so load that content > > > > before calling either function. > > > > > > > > This fixes the display of attached image/jpeg parts, for example. > > > > > > Not so long ago I made an opposite change to avoid fetching useless > > > parts (e.g. audio files). Looks like we need a better check here. Can > > > we know from Content-Type if fetching a part body would be useful? > > > > What if `notmuch-show-insert-part-*/*' consulted a list of content-type > > regexps to attempt to inline? > > > > That would allow a sane default (("image/*" "text/*") perhaps), but also > > allow more to be added to that list (or some to be removed), either by > > code that detected the (in)ability to render it or the user. > > Perhaps there is such a list in mm already? Shouldn't we only be doing this for parts with inline (or not attachment) content-disposition? That's cheap to check. Or do we actually want things like image attachments to get inlined, despite their disposition?