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 85B37431FAF for ; Wed, 18 Jan 2012 12:00:02 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zHi5-n7V7cN3 for ; Wed, 18 Jan 2012 12:00:01 -0800 (PST) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 3FF3C431FAE for ; Wed, 18 Jan 2012 12:00:01 -0800 (PST) Received: by bkty12 with SMTP id y12so2058201bkt.26 for ; Wed, 18 Jan 2012 11:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=Fh2VTPS5qFSDWXtBPzTI9lJhDrUoc4vERx1XFQpoePY=; b=SQRYRVRBetb0UR1IPJNPbuk3de7m9ZITzbOQqliVvrA7yAkdXTEQ9ixlZUjsgYo3yL 4JJNvyGfrowYDreh/vCs7IeowQ8ZxLKEVSYUQEzwideGUou1Of3Fr8wbL1WFytc4+uLO 641RzR7W5R3S7qOS2r8N5gfiT2Fmw86wivvXU= Received: by 10.204.133.213 with SMTP id g21mr9188793bkt.126.1326916799643; Wed, 18 Jan 2012 11:59:59 -0800 (PST) Received: from localhost ([91.144.186.21]) by mx.google.com with ESMTPS id n9sm57053093bkg.8.2012.01.18.11.59.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 Jan 2012 11:59:58 -0800 (PST) From: Dmitry Kurochkin To: Austin Clements Subject: Re: [PATCH v2] emacs: Make the part content available to the mm-inline* checks. In-Reply-To: <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> <20120118193501.GG16740@mit.edu> User-Agent: Notmuch/0.11+73~g8a5402e (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Wed, 18 Jan 2012 23:59:03 +0400 Message-ID: <87zkdk7pfc.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 20:00:02 -0000 On Wed, 18 Jan 2012 14:35:01 -0500, Austin Clements wrote: > 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? It may be good to have this behavior configurable. I would like Emacs to display all part types that it can, independent from content-disposition. Anyway, this is a separate issue. In any case we want to fetch part body only if it is useful. Regards, Dmitry