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=
From: Alexander Botero-Lowry <alex.boterolowry@gmail.com>
To: Carl Worth <cworth@cworth.org>, 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: [notmuch] emacs: On getting support for inline images
Precedence: list

On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> 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