Re: emacs: On getting support for inline images

[micah anderson <micah@riseup.net>]

[-- Attachment #1: Type: text/plain, Size: 3084 bytes --]


On Wed, 10 Feb 2010 12:20:00 -0800, Carl Worth <cworth@cworth.org> wrote:
> I investigated a bit and discovered that the images are being rendered
> within emacs and inside of a temporary buffer that is being used by the
> function invoked by 'v'. Before this function returns, the temporary
> buffer including the nicely inline-rendered image is being killed. (And
> I suspect the exact same thing is happening with encrypted messages
> where hitting 'v' gets emacs to prompt for the passphrase, but then
> nothing is displayed to the user.)
> 
> I was able to get images working by customizing the
> mm-inline-media-tests variable. I removed the image/png clause from the
> value, and now when I hit 'v' I get a nice, external image viewer as
> configured in /etc/mailcap, etc.
> 
> 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'.

This would leave encrypted messages in a weird spot. What external
viewer would you want to be launched when you press 'v' on an encrypted
message? I'd like it to be emacs myself, and even better I want it to be
in notmuch/mml-mode so I can reply to it and get quoting. Although this
option seems like the easiest solution, it avoids the problem, and
unfortunately not very well. Emacs can display images and PDFs fine too,
it just can't do openoffice documents, yet ;)

> 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.

This seems like the right way to handle things in the emacs mode.

> 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).

I would think that the mm functions are probably pretty battle-tested
and have been in a lot of very careful honing over the years. They
probably do the right thing, and do it well because a lot of work has
gone into getting them right. I'm sure there is a big here and there,
but still it seems like it would be a shame not to use something that
has a pretty full feature-set. 

On the other-hand, I see your point about non-emacs clients, and the
command-line having the ability to parse our MIME parts. Perhaps there
is room for both to play?

micah

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]