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 37C55431FC0 for ; Wed, 10 Feb 2010 13:52:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 7sFeNslDMB1k for ; Wed, 10 Feb 2010 13:52:45 -0800 (PST) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by olra.theworths.org (Postfix) with ESMTP id ED00D431FAE for ; Wed, 10 Feb 2010 13:52:44 -0800 (PST) Received: by fxm9 with SMTP id 9so201100fxm.30 for ; Wed, 10 Feb 2010 13:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:to:subject :in-reply-to:references:date:message-id:mime-version:content-type; bh=btqoCGxU4TG6k1GmCWEpzsTq7T/8z8LLnV+EoLEu3k0=; b=G9w5pg6zU1JRLHJPvr2Aqd6cGIAs/2Y36y+8z/Re3P8I0INNa758jAopSfvzUtany9 mtkDL0texCKs3dCw0JhJTwUUiGhdmGJKY5iI1ZSbG3/C3cTEvhUXglLYnNbk73iM4xfb nQG3/r7JkgBRNzXr8ypFaaDiNSE4OmEuJU7WU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:in-reply-to:references:date:message-id:mime-version :content-type; b=dYNekHUztwFvqKiWkGDH8ceKY0SiU6JNphaNOTvMk6ADf98Rqf8CYRRmrWQU/AXCrq 3ChKgaK13DS9wH02zeIr4JRbkgRDa04asJX6gVuPvqwKDKL1FEAqV+5OXrLs64d/VCNT RbF9f3hEPmSY8Gg39xIubvf6+zc4KNxZFokaI= Received: by 10.87.69.17 with SMTP id w17mr4155170fgk.41.1265838763931; Wed, 10 Feb 2010 13:52:43 -0800 (PST) Received: from fortitudo (nat09.metaweb.com [208.68.111.136]) by mx.google.com with ESMTPS id 16sm846399fxm.0.2010.02.10.13.52.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Feb 2010 13:52:40 -0800 (PST) Received: from alexbl (uid 1001) (envelope-from alexbl@fortitudo.i-did-not-set--mail-host-address--so-tickle-me) id a095 by fortitudo (DragonFly Mail Agent) Wed, 10 Feb 2010 13:53:53 -0800 From: Alexander Botero-Lowry To: Carl Worth , notmuch@notmuchmail.org In-Reply-To: <87vde4derz.fsf@yoom.home.cworth.org> References: <87vde4derz.fsf@yoom.home.cworth.org> Date: Wed, 10 Feb 2010 13:53:52 -0800 Message-ID: <866364g3kf.fsf@fortitudo.i-did-not-set--mail-host-address--so-tickle-me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: emacs: On getting support for inline images 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, 10 Feb 2010 21:52:46 -0000 On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth wrote: > For a while I've seen that I can very conveniently deal with attachments > such as PDF files or even OpenOffice (or PowerPoint) presentations with > the notmuch/emacs client. I simply hit 'v' and an external viewer comes > up with the attached file. That's all very nice. > Yeah, though it would b enice if we had more fine-grained control over it, like allowing you to save a file regardless of mm-* thinks it should get to display it or not. > Here are some ideas for possible (and independent) fixes: > > 1. With the current setup, we know we are using a temporary buffer that > the user won't see, so notmuch could temporarily set > mm-inline-media-tests to nil forcing everything to use external > viewers when the user presses 'v'. > I think this is a crappy, but perfectly fine temporary fix. > 2. The original presentation of Mime parts could examine > mm-inline-media-tests and directly render anything possible within > the original presentation of the message. This would allow images to > be viewed directly without requiring the user to press 'v'. And the > user could configure this existing variable to control what content > is displayed inline. > Yes, I think some kind of mapping of interesting parts in the message to the mm-dissect-buffer parts and extending the text/html only inliner to also inline those interesting parts is the right thing (tm). Which points out a huge issue in my current inlining code, the parts aren't actually mapped, we're basically counting on the coincidence that the parts are in the correct place when we do the inlining, and that seems to basically work. That being said, it's the cause of some messages occasionally giving you a save dialog, or failing to be parsed correctly. > 3. We could move away from these various mm- functions for displaying > MIME parts and simply add functionality to the notmuch command line > for extracting individual MIME parts from messages, (which is > something that a non-emacs client will likely want anyway). Then we > can use the lower-level functions to display things directly. (For > example, displaying an image looks as simple as calling the > create-image and put-image functions). > Just talking about this on IRC. I think this is the wrong approach but with some right bits. notmuch cli needs to support saving parts. Period. but mm-* is a very complex and magical library happily used by (almost?) all the emacs mailers. It does a nice job once you learn how to wield its magic correctly (and indeed, one of our bigger problems is the thread-view is something it wasn't really designed for, so we just need to figure out the best-practice for working around that). mm-* should continue to be used, and we need to figure out the right technique for mapping between parts mentioned in the output of notmuch show and the actual parts in the mm-dissect-buffer output. I want to work on this, but I've been kind of busy and not felt like hacking elisp lately, so hopefilly that'll turn around :/ alex